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.cpp

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

218 lines
9.0 KiB
C++
Raw Normal View History

*Really* fix DOS newlines introduced in r210330 r210369 didn't quite catch all of them. llvm-svn: 210593
2014-06-11 05:35:24 +08:00
// RUN: %clang_cc1 -triple x86_64-apple-darwin -std=c++11 -emit-llvm -o - %s | FileCheck %s
// Verify while loop is recognized after sequence of pragma clang loop directives.
void while_test(int *List, int Length) {
// CHECK: define {{.*}} @_Z10while_test
int i = 0;
#pragma clang loop vectorize(enable)
#pragma clang loop interleave_count(4)
#pragma clang loop vectorize_width(4)
In unroll pragma syntax and loop hint metadata, change "enable" forms to a new form using the string "full". llvm-svn: 213771
2014-07-24 01:31:31 +08:00
#pragma clang loop unroll(full)
Add loop pragma for Loop Distribution Summary: This is similar to other loop pragmas like 'vectorize'. Currently it only has state values: distribute(enable) and distribute(disable). When one of these is specified the corresponding loop metadata is generated: !{!"llvm.loop.distribute.enable", i1 true/false} As a result, loop distribution will be attempted on the loop even if Loop Distribution in not enabled globally. Analogously, with 'disable' distribution can be turned off for an individual loop even when the pass is otherwise enabled. There are some slight differences compared to the existing loop pragmas. 1. There is no 'assume_safety' variant which makes its handling slightly different from 'vectorize'/'interleave'. 2. Unlike the existing loop pragmas, it does not have a corresponding numeric pragma like 'vectorize' -> 'vectorize_width'. So for the consistency checks in CheckForIncompatibleAttributes we don't need to check it against other pragmas. We just need to check for duplicates of the same pragma. Reviewers: rsmith, dexonsmith, aaron.ballman Subscribers: bob.wilson, cfe-commits, hfinkel Differential Revision: http://reviews.llvm.org/D19403 llvm-svn: 272656
2016-06-14 20:04:26 +08:00
#pragma clang loop distribute(enable)
*Really* fix DOS newlines introduced in r210330 r210369 didn't quite catch all of them. llvm-svn: 210593
2014-06-11 05:35:24 +08:00
while (i < Length) {
Use CGLoopInfo to emit metadata for loop hint pragmas. When ‘#pragma clang loop vectorize(assume_safety)’ was specified on a loop other loop hints were lost. The problem is that CGLoopInfo attaches metadata differently than EmitCondBrHints in CGStmt. For do-loops CGLoopInfo attaches metadata to the br in the body block and for while and for loops, the inc block. EmitCondBrHints on the other hand always attaches data to the br in the cond block. When specifying assume_safety CGLoopInfo emits an empty llvm.loop metadata shadowing the metadata in the cond block. Loop transformations like rotate and unswitch would then eliminate the cond block and its non-empty metadata. This patch unifies both approaches for adding metadata and modifies the existing safety tests to include non-assume_safety loop hints. llvm-svn: 243315
2015-07-28 04:10:20 +08:00
// CHECK: br label {{.*}}, !llvm.loop ![[LOOP_1:.*]]
*Really* fix DOS newlines introduced in r210330 r210369 didn't quite catch all of them. llvm-svn: 210593
2014-06-11 05:35:24 +08:00
List[i] = i * 2;
i++;
}
}
// Verify do loop is recognized after multi-option pragma clang loop directive.
void do_test(int *List, int Length) {
int i = 0;
Add loop pragma for Loop Distribution Summary: This is similar to other loop pragmas like 'vectorize'. Currently it only has state values: distribute(enable) and distribute(disable). When one of these is specified the corresponding loop metadata is generated: !{!"llvm.loop.distribute.enable", i1 true/false} As a result, loop distribution will be attempted on the loop even if Loop Distribution in not enabled globally. Analogously, with 'disable' distribution can be turned off for an individual loop even when the pass is otherwise enabled. There are some slight differences compared to the existing loop pragmas. 1. There is no 'assume_safety' variant which makes its handling slightly different from 'vectorize'/'interleave'. 2. Unlike the existing loop pragmas, it does not have a corresponding numeric pragma like 'vectorize' -> 'vectorize_width'. So for the consistency checks in CheckForIncompatibleAttributes we don't need to check it against other pragmas. We just need to check for duplicates of the same pragma. Reviewers: rsmith, dexonsmith, aaron.ballman Subscribers: bob.wilson, cfe-commits, hfinkel Differential Revision: http://reviews.llvm.org/D19403 llvm-svn: 272656
2016-06-14 20:04:26 +08:00
#pragma clang loop vectorize_width(8) interleave_count(4) unroll(disable) distribute(disable)
*Really* fix DOS newlines introduced in r210330 r210369 didn't quite catch all of them. llvm-svn: 210593
2014-06-11 05:35:24 +08:00
do {
// CHECK: br i1 {{.*}}, label {{.*}}, label {{.*}}, !llvm.loop ![[LOOP_2:.*]]
List[i] = i * 2;
i++;
} while (i < Length);
}
Allow constant expressions in pragma loop hints. Previously loop hints such as #pragma loop vectorize_width(#) required a constant. This patch allows a constant expression to be used as well. Such as a non-type template parameter or an expression (2 * c + 1). Reviewed by Richard Smith llvm-svn: 219589
2014-10-13 04:46:07 +08:00
enum struct Tuner : short { Interleave = 4, Unroll = 8 };
*Really* fix DOS newlines introduced in r210330 r210369 didn't quite catch all of them. llvm-svn: 210593
2014-06-11 05:35:24 +08:00
// Verify for loop is recognized after sequence of pragma clang loop directives.
void for_test(int *List, int Length) {
#pragma clang loop interleave(enable)
Allow constant expressions in pragma loop hints. Previously loop hints such as #pragma loop vectorize_width(#) required a constant. This patch allows a constant expression to be used as well. Such as a non-type template parameter or an expression (2 * c + 1). Reviewed by Richard Smith llvm-svn: 219589
2014-10-13 04:46:07 +08:00
#pragma clang loop interleave_count(static_cast<int>(Tuner::Interleave))
#pragma clang loop unroll_count(static_cast<int>(Tuner::Unroll))
*Really* fix DOS newlines introduced in r210330 r210369 didn't quite catch all of them. llvm-svn: 210593
2014-06-11 05:35:24 +08:00
for (int i = 0; i < Length; i++) {
Use CGLoopInfo to emit metadata for loop hint pragmas. When ‘#pragma clang loop vectorize(assume_safety)’ was specified on a loop other loop hints were lost. The problem is that CGLoopInfo attaches metadata differently than EmitCondBrHints in CGStmt. For do-loops CGLoopInfo attaches metadata to the br in the body block and for while and for loops, the inc block. EmitCondBrHints on the other hand always attaches data to the br in the cond block. When specifying assume_safety CGLoopInfo emits an empty llvm.loop metadata shadowing the metadata in the cond block. Loop transformations like rotate and unswitch would then eliminate the cond block and its non-empty metadata. This patch unifies both approaches for adding metadata and modifies the existing safety tests to include non-assume_safety loop hints. llvm-svn: 243315
2015-07-28 04:10:20 +08:00
// CHECK: br label {{.*}}, !llvm.loop ![[LOOP_3:.*]]
*Really* fix DOS newlines introduced in r210330 r210369 didn't quite catch all of them. llvm-svn: 210593
2014-06-11 05:35:24 +08:00
List[i] = i * 2;
}
}
// Verify c++11 for range loop is recognized after
// sequence of pragma clang loop directives.
void for_range_test() {
double List[100];
#pragma clang loop vectorize_width(2) interleave_count(2)
for (int i : List) {
Use CGLoopInfo to emit metadata for loop hint pragmas. When ‘#pragma clang loop vectorize(assume_safety)’ was specified on a loop other loop hints were lost. The problem is that CGLoopInfo attaches metadata differently than EmitCondBrHints in CGStmt. For do-loops CGLoopInfo attaches metadata to the br in the body block and for while and for loops, the inc block. EmitCondBrHints on the other hand always attaches data to the br in the cond block. When specifying assume_safety CGLoopInfo emits an empty llvm.loop metadata shadowing the metadata in the cond block. Loop transformations like rotate and unswitch would then eliminate the cond block and its non-empty metadata. This patch unifies both approaches for adding metadata and modifies the existing safety tests to include non-assume_safety loop hints. llvm-svn: 243315
2015-07-28 04:10:20 +08:00
// CHECK: br label {{.*}}, !llvm.loop ![[LOOP_4:.*]]
*Really* fix DOS newlines introduced in r210330 r210369 didn't quite catch all of them. llvm-svn: 210593
2014-06-11 05:35:24 +08:00
List[i] = i;
}
}
// Verify disable pragma clang loop directive generates correct metadata
void disable_test(int *List, int Length) {
Add loop pragma for Loop Distribution Summary: This is similar to other loop pragmas like 'vectorize'. Currently it only has state values: distribute(enable) and distribute(disable). When one of these is specified the corresponding loop metadata is generated: !{!"llvm.loop.distribute.enable", i1 true/false} As a result, loop distribution will be attempted on the loop even if Loop Distribution in not enabled globally. Analogously, with 'disable' distribution can be turned off for an individual loop even when the pass is otherwise enabled. There are some slight differences compared to the existing loop pragmas. 1. There is no 'assume_safety' variant which makes its handling slightly different from 'vectorize'/'interleave'. 2. Unlike the existing loop pragmas, it does not have a corresponding numeric pragma like 'vectorize' -> 'vectorize_width'. So for the consistency checks in CheckForIncompatibleAttributes we don't need to check it against other pragmas. We just need to check for duplicates of the same pragma. Reviewers: rsmith, dexonsmith, aaron.ballman Subscribers: bob.wilson, cfe-commits, hfinkel Differential Revision: http://reviews.llvm.org/D19403 llvm-svn: 272656
2016-06-14 20:04:26 +08:00
#pragma clang loop vectorize(disable) unroll(disable) distribute(disable)
*Really* fix DOS newlines introduced in r210330 r210369 didn't quite catch all of them. llvm-svn: 210593
2014-06-11 05:35:24 +08:00
for (int i = 0; i < Length; i++) {
Use CGLoopInfo to emit metadata for loop hint pragmas. When ‘#pragma clang loop vectorize(assume_safety)’ was specified on a loop other loop hints were lost. The problem is that CGLoopInfo attaches metadata differently than EmitCondBrHints in CGStmt. For do-loops CGLoopInfo attaches metadata to the br in the body block and for while and for loops, the inc block. EmitCondBrHints on the other hand always attaches data to the br in the cond block. When specifying assume_safety CGLoopInfo emits an empty llvm.loop metadata shadowing the metadata in the cond block. Loop transformations like rotate and unswitch would then eliminate the cond block and its non-empty metadata. This patch unifies both approaches for adding metadata and modifies the existing safety tests to include non-assume_safety loop hints. llvm-svn: 243315
2015-07-28 04:10:20 +08:00
// CHECK: br label {{.*}}, !llvm.loop ![[LOOP_5:.*]]
*Really* fix DOS newlines introduced in r210330 r210369 didn't quite catch all of them. llvm-svn: 210593
2014-06-11 05:35:24 +08:00
List[i] = i * 2;
}
}
#define VECWIDTH 2
#define INTCOUNT 2
Add loop unroll pragma support http://reviews.llvm.org/D4089 Patch by Mark Heffernan. llvm-svn: 210667
2014-06-12 01:56:26 +08:00
#define UNROLLCOUNT 8
*Really* fix DOS newlines introduced in r210330 r210369 didn't quite catch all of them. llvm-svn: 210593
2014-06-11 05:35:24 +08:00
// Verify defines are correctly resolved in pragma clang loop directive
void for_define_test(int *List, int Length, int Value) {
#pragma clang loop vectorize_width(VECWIDTH) interleave_count(INTCOUNT)
Add loop unroll pragma support http://reviews.llvm.org/D4089 Patch by Mark Heffernan. llvm-svn: 210667
2014-06-12 01:56:26 +08:00
#pragma clang loop unroll_count(UNROLLCOUNT)
*Really* fix DOS newlines introduced in r210330 r210369 didn't quite catch all of them. llvm-svn: 210593
2014-06-11 05:35:24 +08:00
for (int i = 0; i < Length; i++) {
Use CGLoopInfo to emit metadata for loop hint pragmas. When ‘#pragma clang loop vectorize(assume_safety)’ was specified on a loop other loop hints were lost. The problem is that CGLoopInfo attaches metadata differently than EmitCondBrHints in CGStmt. For do-loops CGLoopInfo attaches metadata to the br in the body block and for while and for loops, the inc block. EmitCondBrHints on the other hand always attaches data to the br in the cond block. When specifying assume_safety CGLoopInfo emits an empty llvm.loop metadata shadowing the metadata in the cond block. Loop transformations like rotate and unswitch would then eliminate the cond block and its non-empty metadata. This patch unifies both approaches for adding metadata and modifies the existing safety tests to include non-assume_safety loop hints. llvm-svn: 243315
2015-07-28 04:10:20 +08:00
// CHECK: br label {{.*}}, !llvm.loop ![[LOOP_6:.*]]
*Really* fix DOS newlines introduced in r210330 r210369 didn't quite catch all of them. llvm-svn: 210593
2014-06-11 05:35:24 +08:00
List[i] = i * Value;
}
}
Allow constant expressions in pragma loop hints. Previously loop hints such as #pragma loop vectorize_width(#) required a constant. This patch allows a constant expression to be used as well. Such as a non-type template parameter or an expression (2 * c + 1). Reviewed by Richard Smith llvm-svn: 219589
2014-10-13 04:46:07 +08:00
// Verify constant expressions are handled correctly.
void for_contant_expression_test(int *List, int Length) {
#pragma clang loop vectorize_width(1 + 4)
for (int i = 0; i < Length; i++) {
Use CGLoopInfo to emit metadata for loop hint pragmas. When ‘#pragma clang loop vectorize(assume_safety)’ was specified on a loop other loop hints were lost. The problem is that CGLoopInfo attaches metadata differently than EmitCondBrHints in CGStmt. For do-loops CGLoopInfo attaches metadata to the br in the body block and for while and for loops, the inc block. EmitCondBrHints on the other hand always attaches data to the br in the cond block. When specifying assume_safety CGLoopInfo emits an empty llvm.loop metadata shadowing the metadata in the cond block. Loop transformations like rotate and unswitch would then eliminate the cond block and its non-empty metadata. This patch unifies both approaches for adding metadata and modifies the existing safety tests to include non-assume_safety loop hints. llvm-svn: 243315
2015-07-28 04:10:20 +08:00
// CHECK: br label {{.*}}, !llvm.loop ![[LOOP_7:.*]]
Allow constant expressions in pragma loop hints. Previously loop hints such as #pragma loop vectorize_width(#) required a constant. This patch allows a constant expression to be used as well. Such as a non-type template parameter or an expression (2 * c + 1). Reviewed by Richard Smith llvm-svn: 219589
2014-10-13 04:46:07 +08:00
List[i] = i;
}
#pragma clang loop vectorize_width(3 + VECWIDTH)
for (int i = 0; i < Length; i++) {
Use CGLoopInfo to emit metadata for loop hint pragmas. When ‘#pragma clang loop vectorize(assume_safety)’ was specified on a loop other loop hints were lost. The problem is that CGLoopInfo attaches metadata differently than EmitCondBrHints in CGStmt. For do-loops CGLoopInfo attaches metadata to the br in the body block and for while and for loops, the inc block. EmitCondBrHints on the other hand always attaches data to the br in the cond block. When specifying assume_safety CGLoopInfo emits an empty llvm.loop metadata shadowing the metadata in the cond block. Loop transformations like rotate and unswitch would then eliminate the cond block and its non-empty metadata. This patch unifies both approaches for adding metadata and modifies the existing safety tests to include non-assume_safety loop hints. llvm-svn: 243315
2015-07-28 04:10:20 +08:00
// CHECK: br label {{.*}}, !llvm.loop ![[LOOP_8:.*]]
Allow constant expressions in pragma loop hints. Previously loop hints such as #pragma loop vectorize_width(#) required a constant. This patch allows a constant expression to be used as well. Such as a non-type template parameter or an expression (2 * c + 1). Reviewed by Richard Smith llvm-svn: 219589
2014-10-13 04:46:07 +08:00
List[i] += i;
}
}
*Really* fix DOS newlines introduced in r210330 r210369 didn't quite catch all of them. llvm-svn: 210593
2014-06-11 05:35:24 +08:00
// Verify metadata is generated when template is used.
template <typename A>
void for_template_test(A *List, int Length, A Value) {
Add loop unroll pragma support http://reviews.llvm.org/D4089 Patch by Mark Heffernan. llvm-svn: 210667
2014-06-12 01:56:26 +08:00
#pragma clang loop vectorize_width(8) interleave_count(8) unroll_count(8)
*Really* fix DOS newlines introduced in r210330 r210369 didn't quite catch all of them. llvm-svn: 210593
2014-06-11 05:35:24 +08:00
for (int i = 0; i < Length; i++) {
Use CGLoopInfo to emit metadata for loop hint pragmas. When ‘#pragma clang loop vectorize(assume_safety)’ was specified on a loop other loop hints were lost. The problem is that CGLoopInfo attaches metadata differently than EmitCondBrHints in CGStmt. For do-loops CGLoopInfo attaches metadata to the br in the body block and for while and for loops, the inc block. EmitCondBrHints on the other hand always attaches data to the br in the cond block. When specifying assume_safety CGLoopInfo emits an empty llvm.loop metadata shadowing the metadata in the cond block. Loop transformations like rotate and unswitch would then eliminate the cond block and its non-empty metadata. This patch unifies both approaches for adding metadata and modifies the existing safety tests to include non-assume_safety loop hints. llvm-svn: 243315
2015-07-28 04:10:20 +08:00
// CHECK: br label {{.*}}, !llvm.loop ![[LOOP_9:.*]]
*Really* fix DOS newlines introduced in r210330 r210369 didn't quite catch all of them. llvm-svn: 210593
2014-06-11 05:35:24 +08:00
List[i] = i * Value;
}
}
// Verify define is resolved correctly when template is used.
Allow constant expressions in pragma loop hints. Previously loop hints such as #pragma loop vectorize_width(#) required a constant. This patch allows a constant expression to be used as well. Such as a non-type template parameter or an expression (2 * c + 1). Reviewed by Richard Smith llvm-svn: 219589
2014-10-13 04:46:07 +08:00
template <typename A, typename T>
*Really* fix DOS newlines introduced in r210330 r210369 didn't quite catch all of them. llvm-svn: 210593
2014-06-11 05:35:24 +08:00
void for_template_define_test(A *List, int Length, A Value) {
Allow constant expressions in pragma loop hints. Previously loop hints such as #pragma loop vectorize_width(#) required a constant. This patch allows a constant expression to be used as well. Such as a non-type template parameter or an expression (2 * c + 1). Reviewed by Richard Smith llvm-svn: 219589
2014-10-13 04:46:07 +08:00
const T VWidth = VECWIDTH;
const T ICount = INTCOUNT;
const T UCount = UNROLLCOUNT;
#pragma clang loop vectorize_width(VWidth) interleave_count(ICount)
#pragma clang loop unroll_count(UCount)
*Really* fix DOS newlines introduced in r210330 r210369 didn't quite catch all of them. llvm-svn: 210593
2014-06-11 05:35:24 +08:00
for (int i = 0; i < Length; i++) {
Use CGLoopInfo to emit metadata for loop hint pragmas. When ‘#pragma clang loop vectorize(assume_safety)’ was specified on a loop other loop hints were lost. The problem is that CGLoopInfo attaches metadata differently than EmitCondBrHints in CGStmt. For do-loops CGLoopInfo attaches metadata to the br in the body block and for while and for loops, the inc block. EmitCondBrHints on the other hand always attaches data to the br in the cond block. When specifying assume_safety CGLoopInfo emits an empty llvm.loop metadata shadowing the metadata in the cond block. Loop transformations like rotate and unswitch would then eliminate the cond block and its non-empty metadata. This patch unifies both approaches for adding metadata and modifies the existing safety tests to include non-assume_safety loop hints. llvm-svn: 243315
2015-07-28 04:10:20 +08:00
// CHECK: br label {{.*}}, !llvm.loop ![[LOOP_10:.*]]
*Really* fix DOS newlines introduced in r210330 r210369 didn't quite catch all of them. llvm-svn: 210593
2014-06-11 05:35:24 +08:00
List[i] = i * Value;
}
}
Allow constant expressions in pragma loop hints. Previously loop hints such as #pragma loop vectorize_width(#) required a constant. This patch allows a constant expression to be used as well. Such as a non-type template parameter or an expression (2 * c + 1). Reviewed by Richard Smith llvm-svn: 219589
2014-10-13 04:46:07 +08:00
// Verify templates and constant expressions are handled correctly.
template <typename A, int V, int I, int U>
void for_template_constant_expression_test(A *List, int Length) {
#pragma clang loop vectorize_width(V) interleave_count(I) unroll_count(U)
for (int i = 0; i < Length; i++) {
Use CGLoopInfo to emit metadata for loop hint pragmas. When ‘#pragma clang loop vectorize(assume_safety)’ was specified on a loop other loop hints were lost. The problem is that CGLoopInfo attaches metadata differently than EmitCondBrHints in CGStmt. For do-loops CGLoopInfo attaches metadata to the br in the body block and for while and for loops, the inc block. EmitCondBrHints on the other hand always attaches data to the br in the cond block. When specifying assume_safety CGLoopInfo emits an empty llvm.loop metadata shadowing the metadata in the cond block. Loop transformations like rotate and unswitch would then eliminate the cond block and its non-empty metadata. This patch unifies both approaches for adding metadata and modifies the existing safety tests to include non-assume_safety loop hints. llvm-svn: 243315
2015-07-28 04:10:20 +08:00
// CHECK: br label {{.*}}, !llvm.loop ![[LOOP_11:.*]]
Allow constant expressions in pragma loop hints. Previously loop hints such as #pragma loop vectorize_width(#) required a constant. This patch allows a constant expression to be used as well. Such as a non-type template parameter or an expression (2 * c + 1). Reviewed by Richard Smith llvm-svn: 219589
2014-10-13 04:46:07 +08:00
List[i] = i;
}
#pragma clang loop vectorize_width(V * 2 + VECWIDTH) interleave_count(I * 2 + INTCOUNT) unroll_count(U * 2 + UNROLLCOUNT)
for (int i = 0; i < Length; i++) {
Use CGLoopInfo to emit metadata for loop hint pragmas. When ‘#pragma clang loop vectorize(assume_safety)’ was specified on a loop other loop hints were lost. The problem is that CGLoopInfo attaches metadata differently than EmitCondBrHints in CGStmt. For do-loops CGLoopInfo attaches metadata to the br in the body block and for while and for loops, the inc block. EmitCondBrHints on the other hand always attaches data to the br in the cond block. When specifying assume_safety CGLoopInfo emits an empty llvm.loop metadata shadowing the metadata in the cond block. Loop transformations like rotate and unswitch would then eliminate the cond block and its non-empty metadata. This patch unifies both approaches for adding metadata and modifies the existing safety tests to include non-assume_safety loop hints. llvm-svn: 243315
2015-07-28 04:10:20 +08:00
// CHECK: br label {{.*}}, !llvm.loop ![[LOOP_12:.*]]
Allow constant expressions in pragma loop hints. Previously loop hints such as #pragma loop vectorize_width(#) required a constant. This patch allows a constant expression to be used as well. Such as a non-type template parameter or an expression (2 * c + 1). Reviewed by Richard Smith llvm-svn: 219589
2014-10-13 04:46:07 +08:00
List[i] += i;
}
const int Scale = 4;
#pragma clang loop vectorize_width(Scale * V) interleave_count(Scale * I) unroll_count(Scale * U)
for (int i = 0; i < Length; i++) {
Use CGLoopInfo to emit metadata for loop hint pragmas. When ‘#pragma clang loop vectorize(assume_safety)’ was specified on a loop other loop hints were lost. The problem is that CGLoopInfo attaches metadata differently than EmitCondBrHints in CGStmt. For do-loops CGLoopInfo attaches metadata to the br in the body block and for while and for loops, the inc block. EmitCondBrHints on the other hand always attaches data to the br in the cond block. When specifying assume_safety CGLoopInfo emits an empty llvm.loop metadata shadowing the metadata in the cond block. Loop transformations like rotate and unswitch would then eliminate the cond block and its non-empty metadata. This patch unifies both approaches for adding metadata and modifies the existing safety tests to include non-assume_safety loop hints. llvm-svn: 243315
2015-07-28 04:10:20 +08:00
// CHECK: br label {{.*}}, !llvm.loop ![[LOOP_13:.*]]
Allow constant expressions in pragma loop hints. Previously loop hints such as #pragma loop vectorize_width(#) required a constant. This patch allows a constant expression to be used as well. Such as a non-type template parameter or an expression (2 * c + 1). Reviewed by Richard Smith llvm-svn: 219589
2014-10-13 04:46:07 +08:00
List[i] += i;
}
#pragma clang loop vectorize_width((Scale * V) + 2)
for (int i = 0; i < Length; i++) {
Use CGLoopInfo to emit metadata for loop hint pragmas. When ‘#pragma clang loop vectorize(assume_safety)’ was specified on a loop other loop hints were lost. The problem is that CGLoopInfo attaches metadata differently than EmitCondBrHints in CGStmt. For do-loops CGLoopInfo attaches metadata to the br in the body block and for while and for loops, the inc block. EmitCondBrHints on the other hand always attaches data to the br in the cond block. When specifying assume_safety CGLoopInfo emits an empty llvm.loop metadata shadowing the metadata in the cond block. Loop transformations like rotate and unswitch would then eliminate the cond block and its non-empty metadata. This patch unifies both approaches for adding metadata and modifies the existing safety tests to include non-assume_safety loop hints. llvm-svn: 243315
2015-07-28 04:10:20 +08:00
// CHECK: br label {{.*}}, !llvm.loop ![[LOOP_14:.*]]
Allow constant expressions in pragma loop hints. Previously loop hints such as #pragma loop vectorize_width(#) required a constant. This patch allows a constant expression to be used as well. Such as a non-type template parameter or an expression (2 * c + 1). Reviewed by Richard Smith llvm-svn: 219589
2014-10-13 04:46:07 +08:00
List[i] += i;
}
}
*Really* fix DOS newlines introduced in r210330 r210369 didn't quite catch all of them. llvm-svn: 210593
2014-06-11 05:35:24 +08:00
#undef VECWIDTH
#undef INTCOUNT
Add loop unroll pragma support http://reviews.llvm.org/D4089 Patch by Mark Heffernan. llvm-svn: 210667
2014-06-12 01:56:26 +08:00
#undef UNROLLCOUNT
*Really* fix DOS newlines introduced in r210330 r210369 didn't quite catch all of them. llvm-svn: 210593
2014-06-11 05:35:24 +08:00
// Use templates defined above. Test verifies metadata is generated correctly.
void template_test(double *List, int Length) {
double Value = 10;
for_template_test<double>(List, Length, Value);
Allow constant expressions in pragma loop hints. Previously loop hints such as #pragma loop vectorize_width(#) required a constant. This patch allows a constant expression to be used as well. Such as a non-type template parameter or an expression (2 * c + 1). Reviewed by Richard Smith llvm-svn: 219589
2014-10-13 04:46:07 +08:00
for_template_define_test<double, int>(List, Length, Value);
for_template_constant_expression_test<double, 2, 4, 8>(List, Length);
*Really* fix DOS newlines introduced in r210330 r210369 didn't quite catch all of them. llvm-svn: 210593
2014-06-11 05:35:24 +08:00
}
[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: ![[LOOP_1]] = distinct !{![[LOOP_1]], ![[UNROLL_FULL:.*]]}
Use CGLoopInfo to emit metadata for loop hint pragmas. When ‘#pragma clang loop vectorize(assume_safety)’ was specified on a loop other loop hints were lost. The problem is that CGLoopInfo attaches metadata differently than EmitCondBrHints in CGStmt. For do-loops CGLoopInfo attaches metadata to the br in the body block and for while and for loops, the inc block. EmitCondBrHints on the other hand always attaches data to the br in the cond block. When specifying assume_safety CGLoopInfo emits an empty llvm.loop metadata shadowing the metadata in the cond block. Loop transformations like rotate and unswitch would then eliminate the cond block and its non-empty metadata. This patch unifies both approaches for adding metadata and modifies the existing safety tests to include non-assume_safety loop hints. llvm-svn: 243315
2015-07-28 04:10:20 +08:00
// CHECK: ![[UNROLL_FULL]] = !{!"llvm.loop.unroll.full"}
[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
[Clang] Pragma vectorize_width() implies vectorize(enable) Let's try this again; this has been reverted/recommited a few times. Last time this got reverted because for this loop: void a() { #pragma clang loop vectorize(disable) for (;;) ; } vectorisation was incorrectly enabled and the vectorize.enable metadata was set due to a logic error. But with this fixed, we now imply vectorisation when: 1) vectorisation is enabled, which means: VectorizeWidth > 1, 2) and don't want to add it when it is disabled or enabled, otherwise we would be incorrectly setting it or duplicating the metadata, respectively. This should fix PR27643. Differential Revision: https://reviews.llvm.org/D69628
2019-12-11 18:37:40 +08:00
// CHECK: ![[LOOP_2]] = distinct !{![[LOOP_2]], ![[UNROLL_DISABLE:.*]], ![[DISTRIBUTE_DISABLE:.*]], ![[WIDTH_8:.*]], ![[INTERLEAVE_4:.*]], ![[VECTORIZE_ENABLE:.*]]}
Use CGLoopInfo to emit metadata for loop hint pragmas. When ‘#pragma clang loop vectorize(assume_safety)’ was specified on a loop other loop hints were lost. The problem is that CGLoopInfo attaches metadata differently than EmitCondBrHints in CGStmt. For do-loops CGLoopInfo attaches metadata to the br in the body block and for while and for loops, the inc block. EmitCondBrHints on the other hand always attaches data to the br in the cond block. When specifying assume_safety CGLoopInfo emits an empty llvm.loop metadata shadowing the metadata in the cond block. Loop transformations like rotate and unswitch would then eliminate the cond block and its non-empty metadata. This patch unifies both approaches for adding metadata and modifies the existing safety tests to include non-assume_safety loop hints. llvm-svn: 243315
2015-07-28 04:10:20 +08:00
// CHECK: ![[UNROLL_DISABLE]] = !{!"llvm.loop.unroll.disable"}
Add loop pragma for Loop Distribution Summary: This is similar to other loop pragmas like 'vectorize'. Currently it only has state values: distribute(enable) and distribute(disable). When one of these is specified the corresponding loop metadata is generated: !{!"llvm.loop.distribute.enable", i1 true/false} As a result, loop distribution will be attempted on the loop even if Loop Distribution in not enabled globally. Analogously, with 'disable' distribution can be turned off for an individual loop even when the pass is otherwise enabled. There are some slight differences compared to the existing loop pragmas. 1. There is no 'assume_safety' variant which makes its handling slightly different from 'vectorize'/'interleave'. 2. Unlike the existing loop pragmas, it does not have a corresponding numeric pragma like 'vectorize' -> 'vectorize_width'. So for the consistency checks in CheckForIncompatibleAttributes we don't need to check it against other pragmas. We just need to check for duplicates of the same pragma. Reviewers: rsmith, dexonsmith, aaron.ballman Subscribers: bob.wilson, cfe-commits, hfinkel Differential Revision: http://reviews.llvm.org/D19403 llvm-svn: 272656
2016-06-14 20:04:26 +08:00
// CHECK: ![[DISTRIBUTE_DISABLE]] = !{!"llvm.loop.distribute.enable", i1 false}
[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: ![[WIDTH_8]] = !{!"llvm.loop.vectorize.width", i32 8}
// CHECK: ![[INTERLEAVE_4]] = !{!"llvm.loop.interleave.count", i32 4}
[Clang] Pragma vectorize_width() implies vectorize(enable) Let's try this again; this has been reverted/recommited a few times. Last time this got reverted because for this loop: void a() { #pragma clang loop vectorize(disable) for (;;) ; } vectorisation was incorrectly enabled and the vectorize.enable metadata was set due to a logic error. But with this fixed, we now imply vectorisation when: 1) vectorisation is enabled, which means: VectorizeWidth > 1, 2) and don't want to add it when it is disabled or enabled, otherwise we would be incorrectly setting it or duplicating the metadata, respectively. This should fix PR27643. Differential Revision: https://reviews.llvm.org/D69628
2019-12-11 18:37:40 +08:00
// CHECK: ![[VECTORIZE_ENABLE]] = !{!"llvm.loop.vectorize.enable", i1 true}
[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
[Clang] Pragma vectorize_width() implies vectorize(enable) Let's try this again; this has been reverted/recommited a few times. Last time this got reverted because for this loop: void a() { #pragma clang loop vectorize(disable) for (;;) ; } vectorisation was incorrectly enabled and the vectorize.enable metadata was set due to a logic error. But with this fixed, we now imply vectorisation when: 1) vectorisation is enabled, which means: VectorizeWidth > 1, 2) and don't want to add it when it is disabled or enabled, otherwise we would be incorrectly setting it or duplicating the metadata, respectively. This should fix PR27643. Differential Revision: https://reviews.llvm.org/D69628
2019-12-11 18:37:40 +08:00
// CHECK: ![[LOOP_3]] = distinct !{![[LOOP_3]], ![[INTERLEAVE_4:.*]], ![[VECTORIZE_ENABLE]], ![[FOLLOWUP_VECTOR_3:.*]]}
[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: ![[FOLLOWUP_VECTOR_3]] = !{!"llvm.loop.vectorize.followup_all", ![[AFTER_VECTOR_3:.*]]}
// CHECK: ![[AFTER_VECTOR_3]] = distinct !{![[AFTER_VECTOR_3]], ![[ISVECTORIZED:.*]], ![[UNROLL_8:.*]]}
// CHECK: ![[ISVECTORIZED]] = !{!"llvm.loop.isvectorized"}
IR: Make metadata typeless in assembly, clang side Match LLVM changes from r224257. llvm-svn: 224259
2014-12-16 03:10:08 +08:00
// CHECK: ![[UNROLL_8]] = !{!"llvm.loop.unroll.count", i32 8}
[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
[Clang] Pragma vectorize_width() implies vectorize(enable) Let's try this again; this has been reverted/recommited a few times. Last time this got reverted because for this loop: void a() { #pragma clang loop vectorize(disable) for (;;) ; } vectorisation was incorrectly enabled and the vectorize.enable metadata was set due to a logic error. But with this fixed, we now imply vectorisation when: 1) vectorisation is enabled, which means: VectorizeWidth > 1, 2) and don't want to add it when it is disabled or enabled, otherwise we would be incorrectly setting it or duplicating the metadata, respectively. This should fix PR27643. Differential Revision: https://reviews.llvm.org/D69628
2019-12-11 18:37:40 +08:00
// CHECK: ![[LOOP_4]] = distinct !{![[LOOP_4]], ![[WIDTH_2:.*]], ![[INTERLEAVE_2:.*]], ![[VECTORIZE_ENABLE]]}
IR: Make metadata typeless in assembly, clang side Match LLVM changes from r224257. llvm-svn: 224259
2014-12-16 03:10:08 +08:00
// CHECK: ![[WIDTH_2]] = !{!"llvm.loop.vectorize.width", i32 2}
Use CGLoopInfo to emit metadata for loop hint pragmas. When ‘#pragma clang loop vectorize(assume_safety)’ was specified on a loop other loop hints were lost. The problem is that CGLoopInfo attaches metadata differently than EmitCondBrHints in CGStmt. For do-loops CGLoopInfo attaches metadata to the br in the body block and for while and for loops, the inc block. EmitCondBrHints on the other hand always attaches data to the br in the cond block. When specifying assume_safety CGLoopInfo emits an empty llvm.loop metadata shadowing the metadata in the cond block. Loop transformations like rotate and unswitch would then eliminate the cond block and its non-empty metadata. This patch unifies both approaches for adding metadata and modifies the existing safety tests to include non-assume_safety loop hints. llvm-svn: 243315
2015-07-28 04:10:20 +08:00
// CHECK: ![[INTERLEAVE_2]] = !{!"llvm.loop.interleave.count", i32 2}
[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: ![[LOOP_5]] = distinct !{![[LOOP_5]], ![[UNROLL_DISABLE:.*]], ![[DISTRIBUTE_DISABLE:.*]], ![[WIDTH_1:.*]]}
IR: Make metadata typeless in assembly, clang side Match LLVM changes from r224257. llvm-svn: 224259
2014-12-16 03:10:08 +08:00
// CHECK: ![[WIDTH_1]] = !{!"llvm.loop.vectorize.width", i32 1}
[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: ![[LOOP_6]] = distinct !{![[LOOP_6]], ![[WIDTH_2:.*]], ![[INTERLEAVE_2:.*]], ![[FOLLOWUP_VECTOR_6:.*]]}
// CHECK: ![[FOLLOWUP_VECTOR_6]] = !{!"llvm.loop.vectorize.followup_all", ![[AFTER_VECTOR_6:.*]]}
// CHECK: ![[AFTER_VECTOR_6]] = distinct !{![[AFTER_VECTOR_6]], ![[ISVECTORIZED:.*]], ![[UNROLL_8:.*]]}
[Clang] Pragma vectorize_width() implies vectorize(enable) Let's try this again; this has been reverted/recommited a few times. Last time this got reverted because for this loop: void a() { #pragma clang loop vectorize(disable) for (;;) ; } vectorisation was incorrectly enabled and the vectorize.enable metadata was set due to a logic error. But with this fixed, we now imply vectorisation when: 1) vectorisation is enabled, which means: VectorizeWidth > 1, 2) and don't want to add it when it is disabled or enabled, otherwise we would be incorrectly setting it or duplicating the metadata, respectively. This should fix PR27643. Differential Revision: https://reviews.llvm.org/D69628
2019-12-11 18:37:40 +08:00
// CHECK: ![[LOOP_7]] = distinct !{![[LOOP_7]], ![[WIDTH_5:.*]], ![[VECTORIZE_ENABLE]]}
IR: Make metadata typeless in assembly, clang side Match LLVM changes from r224257. llvm-svn: 224259
2014-12-16 03:10:08 +08:00
// CHECK: ![[WIDTH_5]] = !{!"llvm.loop.vectorize.width", i32 5}
[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
IR: Add 'distinct' MDNodes to bitcode and assembly (clang) Update testcases for LLVM change in r225474 to make `MDNode`s explicitly distinct (when they aren't uniqued). Part of PR22111. llvm-svn: 225475
2015-01-09 06:39:28 +08:00
// CHECK: ![[LOOP_8]] = distinct !{![[LOOP_8]], ![[WIDTH_5:.*]]}
[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: ![[LOOP_9]] = distinct !{![[LOOP_9]], ![[WIDTH_8:.*]], ![[INTERLEAVE_8:.*]], ![[FOLLOWUP_VECTOR_9:.*]]}
// CHECK: ![[FOLLOWUP_VECTOR_9]] = !{!"llvm.loop.vectorize.followup_all", ![[AFTER_VECTOR_9:.*]]}
// CHECK: ![[AFTER_VECTOR_9]] = distinct !{![[AFTER_VECTOR_9]], ![[ISVECTORIZED:.*]], ![[UNROLL_8:.*]]}
// CHECK: ![[LOOP_10]] = distinct !{![[LOOP_10]], ![[WIDTH_2:.*]], ![[INTERLEAVE_2:.*]], ![[FOLLOWUP_VECTOR_10:.*]]}
// CHECK: ![[FOLLOWUP_VECTOR_10]] = !{!"llvm.loop.vectorize.followup_all", ![[AFTER_VECTOR_10:.*]]}
// CHECK: ![[AFTER_VECTOR_10]] = distinct !{![[AFTER_VECTOR_10]], ![[ISVECTORIZED:.*]], ![[UNROLL_8:.*]]}
// CHECK: ![[LOOP_11]] = distinct !{![[LOOP_11]], ![[WIDTH_2:.*]], ![[INTERLEAVE_4:.*]], ![[FOLLOWUP_VECTOR_11:.*]]}
// CHECK: ![[FOLLOWUP_VECTOR_11]] = !{!"llvm.loop.vectorize.followup_all", ![[AFTER_VECTOR_11:.*]]}
// CHECK: ![[AFTER_VECTOR_11]] = distinct !{![[AFTER_VECTOR_11]], ![[ISVECTORIZED:.*]], ![[UNROLL_8:.*]]}
// CHECK: ![[LOOP_12]] = distinct !{![[LOOP_12]], ![[WIDTH_6:.*]], ![[INTERLEAVE_10:.*]], ![[FOLLOWUP_VECTOR_12:.*]]}
// CHECK: ![[FOLLOWUP_VECTOR_12]] = !{!"llvm.loop.vectorize.followup_all", ![[AFTER_VECTOR_12:.*]]}
// CHECK: ![[AFTER_VECTOR_12]] = distinct !{![[AFTER_VECTOR_12]], ![[ISVECTORIZED:.*]], ![[UNROLL_24:.*]]}
Use CGLoopInfo to emit metadata for loop hint pragmas. When ‘#pragma clang loop vectorize(assume_safety)’ was specified on a loop other loop hints were lost. The problem is that CGLoopInfo attaches metadata differently than EmitCondBrHints in CGStmt. For do-loops CGLoopInfo attaches metadata to the br in the body block and for while and for loops, the inc block. EmitCondBrHints on the other hand always attaches data to the br in the cond block. When specifying assume_safety CGLoopInfo emits an empty llvm.loop metadata shadowing the metadata in the cond block. Loop transformations like rotate and unswitch would then eliminate the cond block and its non-empty metadata. This patch unifies both approaches for adding metadata and modifies the existing safety tests to include non-assume_safety loop hints. llvm-svn: 243315
2015-07-28 04:10:20 +08:00
// CHECK: ![[UNROLL_24]] = !{!"llvm.loop.unroll.count", i32 24}
[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
[Clang] Pragma vectorize_width() implies vectorize(enable) Let's try this again; this has been reverted/recommited a few times. Last time this got reverted because for this loop: void a() { #pragma clang loop vectorize(disable) for (;;) ; } vectorisation was incorrectly enabled and the vectorize.enable metadata was set due to a logic error. But with this fixed, we now imply vectorisation when: 1) vectorisation is enabled, which means: VectorizeWidth > 1, 2) and don't want to add it when it is disabled or enabled, otherwise we would be incorrectly setting it or duplicating the metadata, respectively. This should fix PR27643. Differential Revision: https://reviews.llvm.org/D69628
2019-12-11 18:37:40 +08:00
// CHECK: ![[LOOP_13]] = distinct !{![[LOOP_13]], ![[WIDTH_8:.*]], ![[INTERLEAVE_16:.*]], ![[VECTORIZE_ENABLE]], ![[FOLLOWUP_VECTOR_13:.*]]}
IR: Make metadata typeless in assembly, clang side Match LLVM changes from r224257. llvm-svn: 224259
2014-12-16 03:10:08 +08:00
// CHECK: ![[INTERLEAVE_16]] = !{!"llvm.loop.interleave.count", i32 16}
[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: ![[FOLLOWUP_VECTOR_13]] = !{!"llvm.loop.vectorize.followup_all", ![[AFTER_VECTOR_13:.*]]}
// CHECK: ![[AFTER_VECTOR_13]] = distinct !{![[AFTER_VECTOR_13]], ![[ISVECTORIZED:.*]], ![[UNROLL_32:.*]]}
Use CGLoopInfo to emit metadata for loop hint pragmas. When ‘#pragma clang loop vectorize(assume_safety)’ was specified on a loop other loop hints were lost. The problem is that CGLoopInfo attaches metadata differently than EmitCondBrHints in CGStmt. For do-loops CGLoopInfo attaches metadata to the br in the body block and for while and for loops, the inc block. EmitCondBrHints on the other hand always attaches data to the br in the cond block. When specifying assume_safety CGLoopInfo emits an empty llvm.loop metadata shadowing the metadata in the cond block. Loop transformations like rotate and unswitch would then eliminate the cond block and its non-empty metadata. This patch unifies both approaches for adding metadata and modifies the existing safety tests to include non-assume_safety loop hints. llvm-svn: 243315
2015-07-28 04:10:20 +08:00
// CHECK: ![[UNROLL_32]] = !{!"llvm.loop.unroll.count", i32 32}
[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
[Clang] Pragma vectorize_width() implies vectorize(enable) Let's try this again; this has been reverted/recommited a few times. Last time this got reverted because for this loop: void a() { #pragma clang loop vectorize(disable) for (;;) ; } vectorisation was incorrectly enabled and the vectorize.enable metadata was set due to a logic error. But with this fixed, we now imply vectorisation when: 1) vectorisation is enabled, which means: VectorizeWidth > 1, 2) and don't want to add it when it is disabled or enabled, otherwise we would be incorrectly setting it or duplicating the metadata, respectively. This should fix PR27643. Differential Revision: https://reviews.llvm.org/D69628
2019-12-11 18:37:40 +08:00
// CHECK: ![[LOOP_14]] = distinct !{![[LOOP_14]], ![[WIDTH_10:.*]], ![[VECTORIZE_ENABLE]]}
IR: Make metadata typeless in assembly, clang side Match LLVM changes from r224257. llvm-svn: 224259
2014-12-16 03:10:08 +08:00
// CHECK: ![[WIDTH_10]] = !{!"llvm.loop.vectorize.width", i32 10}