2014-03-11 12:37:49 +08:00
|
|
|
// Test instrumentation of C++ exception handling constructs.
|
2014-01-07 06:27:43 +08:00
|
|
|
|
2014-01-07 08:59:39 +08:00
|
|
|
// FIXME: Don't seek bb labels, like "if.else"
|
|
|
|
|
// REQUIRES: asserts
|
|
|
|
|
|
2016-04-23 10:11:16 +08:00
|
|
|
// RUN: %clang_cc1 %s -o - -emit-llvm -fprofile-instrument=clang -fexceptions -fcxx-exceptions -triple %itanium_abi_triple | FileCheck -check-prefix=PGOGEN %s
|
|
|
|
|
// RUN: %clang_cc1 %s -o - -emit-llvm -fprofile-instrument=clang -fexceptions -fcxx-exceptions -triple %itanium_abi_triple | FileCheck -check-prefix=PGOGEN-EXC %s
|
2014-01-07 06:27:43 +08:00
|
|
|
|
2014-04-18 06:49:06 +08:00
|
|
|
// RUN: llvm-profdata merge %S/Inputs/cxx-throws.proftext -o %t.profdata
|
2016-04-23 10:11:16 +08:00
|
|
|
// RUN: %clang_cc1 %s -o - -emit-llvm -fprofile-instrument-use-path=%t.profdata -fexceptions -fcxx-exceptions -triple %itanium_abi_triple | FileCheck -check-prefix=PGOUSE %s
|
|
|
|
|
// RUN: %clang_cc1 %s -o - -emit-llvm -fprofile-instrument-use-path=%t.profdata -fexceptions -fcxx-exceptions -triple %itanium_abi_triple | FileCheck -check-prefix=PGOUSE-EXC %s
|
2014-01-07 06:27:43 +08:00
|
|
|
|
2015-12-15 08:33:12 +08:00
|
|
|
// PGOGEN: @[[THC:__profc__Z6throwsv]] = private global [9 x i64] zeroinitializer
|
|
|
|
|
// PGOGEN-EXC: @[[THC:__profc__Z6throwsv]] = private global [9 x i64] zeroinitializer
|
|
|
|
|
// PGOGEN: @[[UNC:__profc__Z11unreachablei]] = private global [3 x i64] zeroinitializer
|
2014-01-07 06:27:43 +08:00
|
|
|
|
|
|
|
|
// PGOGEN-LABEL: @_Z6throwsv()
|
|
|
|
|
// PGOUSE-LABEL: @_Z6throwsv()
|
|
|
|
|
// PGOGEN: store {{.*}} @[[THC]], i64 0, i64 0
|
|
|
|
|
void throws() {
|
|
|
|
|
// PGOGEN: store {{.*}} @[[THC]], i64 0, i64 1
|
|
|
|
|
// PGOUSE: br {{.*}} !prof ![[TH1:[0-9]+]]
|
|
|
|
|
for (int i = 0; i < 100; ++i) {
|
|
|
|
|
try {
|
Change PGO instrumentation to compute counts in a separate AST traversal.
Previously, we made one traversal of the AST prior to codegen to assign
counters to the ASTs and then propagated the count values during codegen. This
patch now adds a separate AST traversal prior to codegen for the
-fprofile-instr-use option to propagate the count values. The counts are then
saved in a map from which they can be retrieved during codegen.
This new approach has several advantages:
1. It gets rid of a lot of extra PGO-related code that had previously been
added to codegen.
2. It fixes a serious bug. My original implementation (which was mailed to the
list but never committed) used 3 counters for every loop. Justin improved it to
move 2 of those counters into the less-frequently executed breaks and continues,
but that turned out to produce wrong count values in some cases. The solution
requires visiting a loop body before the condition so that the count for the
condition properly includes the break and continue counts. Changing codegen to
visit a loop body first would be a fairly invasive change, but with a separate
AST traversal, it is easy to control the order of traversal. I've added a
testcase (provided by Justin) to make sure this works correctly.
3. It improves the instrumentation overhead, reducing the number of counters for
a loop from 3 to 1. We no longer need dedicated counters for breaks and
continues, since we can just use the propagated count values when visiting
breaks and continues.
To make this work, I needed to make a change to the way we count case
statements, going back to my original approach of not including the fall-through
in the counter values. This was necessary because there isn't always an AST node
that can be used to record the fall-through count. Now case statements are
handled the same as default statements, with the fall-through paths branching
over the counter increments. While I was at it, I also went back to using this
approach for do-loops -- omitting the fall-through count into the loop body
simplifies some of the calculations and make them behave the same as other
loops. Whenever we start using this instrumentation for coverage, we'll need
to add the fall-through counts into the counter values.
llvm-svn: 201528
2014-02-18 03:21:09 +08:00
|
|
|
// PGOGEN: store {{.*}} @[[THC]], i64 0, i64 3
|
2014-01-07 06:27:43 +08:00
|
|
|
// PGOUSE: br {{.*}} !prof ![[TH2:[0-9]+]]
|
|
|
|
|
if (i % 3) {
|
Change PGO instrumentation to compute counts in a separate AST traversal.
Previously, we made one traversal of the AST prior to codegen to assign
counters to the ASTs and then propagated the count values during codegen. This
patch now adds a separate AST traversal prior to codegen for the
-fprofile-instr-use option to propagate the count values. The counts are then
saved in a map from which they can be retrieved during codegen.
This new approach has several advantages:
1. It gets rid of a lot of extra PGO-related code that had previously been
added to codegen.
2. It fixes a serious bug. My original implementation (which was mailed to the
list but never committed) used 3 counters for every loop. Justin improved it to
move 2 of those counters into the less-frequently executed breaks and continues,
but that turned out to produce wrong count values in some cases. The solution
requires visiting a loop body before the condition so that the count for the
condition properly includes the break and continue counts. Changing codegen to
visit a loop body first would be a fairly invasive change, but with a separate
AST traversal, it is easy to control the order of traversal. I've added a
testcase (provided by Justin) to make sure this works correctly.
3. It improves the instrumentation overhead, reducing the number of counters for
a loop from 3 to 1. We no longer need dedicated counters for breaks and
continues, since we can just use the propagated count values when visiting
breaks and continues.
To make this work, I needed to make a change to the way we count case
statements, going back to my original approach of not including the fall-through
in the counter values. This was necessary because there isn't always an AST node
that can be used to record the fall-through count. Now case statements are
handled the same as default statements, with the fall-through paths branching
over the counter increments. While I was at it, I also went back to using this
approach for do-loops -- omitting the fall-through count into the loop body
simplifies some of the calculations and make them behave the same as other
loops. Whenever we start using this instrumentation for coverage, we'll need
to add the fall-through counts into the counter values.
llvm-svn: 201528
2014-02-18 03:21:09 +08:00
|
|
|
// PGOGEN: store {{.*}} @[[THC]], i64 0, i64 4
|
2014-01-07 06:27:43 +08:00
|
|
|
// PGOUSE: br {{.*}} !prof ![[TH3:[0-9]+]]
|
|
|
|
|
if (i < 50)
|
|
|
|
|
throw 1;
|
|
|
|
|
} else {
|
|
|
|
|
// The catch block may be emitted after the throw above, we can skip it
|
|
|
|
|
// by looking for an else block, but this will break if anyone puts an
|
|
|
|
|
// else in the catch
|
|
|
|
|
// PGOUSE: if.else{{.*}}:
|
|
|
|
|
// PGOGEN: if.else{{.*}}:
|
|
|
|
|
|
Change PGO instrumentation to compute counts in a separate AST traversal.
Previously, we made one traversal of the AST prior to codegen to assign
counters to the ASTs and then propagated the count values during codegen. This
patch now adds a separate AST traversal prior to codegen for the
-fprofile-instr-use option to propagate the count values. The counts are then
saved in a map from which they can be retrieved during codegen.
This new approach has several advantages:
1. It gets rid of a lot of extra PGO-related code that had previously been
added to codegen.
2. It fixes a serious bug. My original implementation (which was mailed to the
list but never committed) used 3 counters for every loop. Justin improved it to
move 2 of those counters into the less-frequently executed breaks and continues,
but that turned out to produce wrong count values in some cases. The solution
requires visiting a loop body before the condition so that the count for the
condition properly includes the break and continue counts. Changing codegen to
visit a loop body first would be a fairly invasive change, but with a separate
AST traversal, it is easy to control the order of traversal. I've added a
testcase (provided by Justin) to make sure this works correctly.
3. It improves the instrumentation overhead, reducing the number of counters for
a loop from 3 to 1. We no longer need dedicated counters for breaks and
continues, since we can just use the propagated count values when visiting
breaks and continues.
To make this work, I needed to make a change to the way we count case
statements, going back to my original approach of not including the fall-through
in the counter values. This was necessary because there isn't always an AST node
that can be used to record the fall-through count. Now case statements are
handled the same as default statements, with the fall-through paths branching
over the counter increments. While I was at it, I also went back to using this
approach for do-loops -- omitting the fall-through count into the loop body
simplifies some of the calculations and make them behave the same as other
loops. Whenever we start using this instrumentation for coverage, we'll need
to add the fall-through counts into the counter values.
llvm-svn: 201528
2014-02-18 03:21:09 +08:00
|
|
|
// PGOGEN: store {{.*}} @[[THC]], i64 0, i64 5
|
2014-01-07 06:27:43 +08:00
|
|
|
// PGOUSE: br {{.*}} !prof ![[TH4:[0-9]+]]
|
|
|
|
|
if (i >= 50)
|
|
|
|
|
throw 0;
|
|
|
|
|
}
|
|
|
|
|
} catch (int e) {
|
|
|
|
|
// PGOUSE-EXC: catch{{.*}}:
|
|
|
|
|
// PGOGEN-EXC: catch{{.*}}:
|
|
|
|
|
|
Change PGO instrumentation to compute counts in a separate AST traversal.
Previously, we made one traversal of the AST prior to codegen to assign
counters to the ASTs and then propagated the count values during codegen. This
patch now adds a separate AST traversal prior to codegen for the
-fprofile-instr-use option to propagate the count values. The counts are then
saved in a map from which they can be retrieved during codegen.
This new approach has several advantages:
1. It gets rid of a lot of extra PGO-related code that had previously been
added to codegen.
2. It fixes a serious bug. My original implementation (which was mailed to the
list but never committed) used 3 counters for every loop. Justin improved it to
move 2 of those counters into the less-frequently executed breaks and continues,
but that turned out to produce wrong count values in some cases. The solution
requires visiting a loop body before the condition so that the count for the
condition properly includes the break and continue counts. Changing codegen to
visit a loop body first would be a fairly invasive change, but with a separate
AST traversal, it is easy to control the order of traversal. I've added a
testcase (provided by Justin) to make sure this works correctly.
3. It improves the instrumentation overhead, reducing the number of counters for
a loop from 3 to 1. We no longer need dedicated counters for breaks and
continues, since we can just use the propagated count values when visiting
breaks and continues.
To make this work, I needed to make a change to the way we count case
statements, going back to my original approach of not including the fall-through
in the counter values. This was necessary because there isn't always an AST node
that can be used to record the fall-through count. Now case statements are
handled the same as default statements, with the fall-through paths branching
over the counter increments. While I was at it, I also went back to using this
approach for do-loops -- omitting the fall-through count into the loop body
simplifies some of the calculations and make them behave the same as other
loops. Whenever we start using this instrumentation for coverage, we'll need
to add the fall-through counts into the counter values.
llvm-svn: 201528
2014-02-18 03:21:09 +08:00
|
|
|
// PGOGEN-EXC: store {{.*}} @[[THC]], i64 0, i64 6
|
|
|
|
|
// PGOGEN-EXC: store {{.*}} @[[THC]], i64 0, i64 7
|
2014-01-07 06:27:43 +08:00
|
|
|
// PGOUSE-EXC: br {{.*}} !prof ![[TH5:[0-9]+]]
|
|
|
|
|
if (e) {}
|
|
|
|
|
}
|
Change PGO instrumentation to compute counts in a separate AST traversal.
Previously, we made one traversal of the AST prior to codegen to assign
counters to the ASTs and then propagated the count values during codegen. This
patch now adds a separate AST traversal prior to codegen for the
-fprofile-instr-use option to propagate the count values. The counts are then
saved in a map from which they can be retrieved during codegen.
This new approach has several advantages:
1. It gets rid of a lot of extra PGO-related code that had previously been
added to codegen.
2. It fixes a serious bug. My original implementation (which was mailed to the
list but never committed) used 3 counters for every loop. Justin improved it to
move 2 of those counters into the less-frequently executed breaks and continues,
but that turned out to produce wrong count values in some cases. The solution
requires visiting a loop body before the condition so that the count for the
condition properly includes the break and continue counts. Changing codegen to
visit a loop body first would be a fairly invasive change, but with a separate
AST traversal, it is easy to control the order of traversal. I've added a
testcase (provided by Justin) to make sure this works correctly.
3. It improves the instrumentation overhead, reducing the number of counters for
a loop from 3 to 1. We no longer need dedicated counters for breaks and
continues, since we can just use the propagated count values when visiting
breaks and continues.
To make this work, I needed to make a change to the way we count case
statements, going back to my original approach of not including the fall-through
in the counter values. This was necessary because there isn't always an AST node
that can be used to record the fall-through count. Now case statements are
handled the same as default statements, with the fall-through paths branching
over the counter increments. While I was at it, I also went back to using this
approach for do-loops -- omitting the fall-through count into the loop body
simplifies some of the calculations and make them behave the same as other
loops. Whenever we start using this instrumentation for coverage, we'll need
to add the fall-through counts into the counter values.
llvm-svn: 201528
2014-02-18 03:21:09 +08:00
|
|
|
// PGOGEN: store {{.*}} @[[THC]], i64 0, i64 2
|
2014-01-07 06:27:43 +08:00
|
|
|
|
Change PGO instrumentation to compute counts in a separate AST traversal.
Previously, we made one traversal of the AST prior to codegen to assign
counters to the ASTs and then propagated the count values during codegen. This
patch now adds a separate AST traversal prior to codegen for the
-fprofile-instr-use option to propagate the count values. The counts are then
saved in a map from which they can be retrieved during codegen.
This new approach has several advantages:
1. It gets rid of a lot of extra PGO-related code that had previously been
added to codegen.
2. It fixes a serious bug. My original implementation (which was mailed to the
list but never committed) used 3 counters for every loop. Justin improved it to
move 2 of those counters into the less-frequently executed breaks and continues,
but that turned out to produce wrong count values in some cases. The solution
requires visiting a loop body before the condition so that the count for the
condition properly includes the break and continue counts. Changing codegen to
visit a loop body first would be a fairly invasive change, but with a separate
AST traversal, it is easy to control the order of traversal. I've added a
testcase (provided by Justin) to make sure this works correctly.
3. It improves the instrumentation overhead, reducing the number of counters for
a loop from 3 to 1. We no longer need dedicated counters for breaks and
continues, since we can just use the propagated count values when visiting
breaks and continues.
To make this work, I needed to make a change to the way we count case
statements, going back to my original approach of not including the fall-through
in the counter values. This was necessary because there isn't always an AST node
that can be used to record the fall-through count. Now case statements are
handled the same as default statements, with the fall-through paths branching
over the counter increments. While I was at it, I also went back to using this
approach for do-loops -- omitting the fall-through count into the loop body
simplifies some of the calculations and make them behave the same as other
loops. Whenever we start using this instrumentation for coverage, we'll need
to add the fall-through counts into the counter values.
llvm-svn: 201528
2014-02-18 03:21:09 +08:00
|
|
|
// PGOGEN: store {{.*}} @[[THC]], i64 0, i64 8
|
2014-01-07 06:27:43 +08:00
|
|
|
// PGOUSE: br {{.*}} !prof ![[TH6:[0-9]+]]
|
|
|
|
|
if (i < 100) {}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// PGOUSE-NOT: br {{.*}} !prof ![0-9]+
|
|
|
|
|
// PGOUSE: ret void
|
|
|
|
|
}
|
|
|
|
|
|
2015-04-28 14:55:23 +08:00
|
|
|
// PGOGEN-LABEL: @_Z11unreachablei(i32
|
|
|
|
|
// PGOUSE-LABEL: @_Z11unreachablei(i32
|
2015-04-28 14:31:55 +08:00
|
|
|
// PGOGEN: store {{.*}} @[[UNC]], i64 0, i64 0
|
|
|
|
|
void unreachable(int i) {
|
|
|
|
|
// PGOGEN: store {{.*}} @[[UNC]], i64 0, i64 1
|
|
|
|
|
// PGOUSE: br {{.*}} !prof ![[UN1:[0-9]+]]
|
|
|
|
|
if (i)
|
|
|
|
|
throw i;
|
|
|
|
|
|
|
|
|
|
// PGOGEN: store {{.*}} @[[UNC]], i64 0, i64 2
|
|
|
|
|
// Since we never reach here, the weights should all be zero (and skipped)
|
|
|
|
|
// PGOUSE-NOT: br {{.*}} !prof !{{.*}}
|
|
|
|
|
if (i) {}
|
|
|
|
|
}
|
|
|
|
|
|
2014-12-16 03:10:08 +08:00
|
|
|
// PGOUSE-DAG: ![[TH1]] = !{!"branch_weights", i32 101, i32 2}
|
|
|
|
|
// PGOUSE-DAG: ![[TH2]] = !{!"branch_weights", i32 67, i32 35}
|
|
|
|
|
// PGOUSE-DAG: ![[TH3]] = !{!"branch_weights", i32 34, i32 34}
|
|
|
|
|
// PGOUSE-DAG: ![[TH4]] = !{!"branch_weights", i32 18, i32 18}
|
|
|
|
|
// PGOUSE-EXC: ![[TH5]] = !{!"branch_weights", i32 34, i32 18}
|
|
|
|
|
// PGOUSE-DAG: ![[TH6]] = !{!"branch_weights", i32 101, i32 1}
|
2015-04-28 14:31:55 +08:00
|
|
|
// PGOUSE-DAG: ![[UN1]] = !{!"branch_weights", i32 2, i32 1}
|
2014-01-07 06:27:43 +08:00
|
|
|
|
|
|
|
|
int main(int argc, const char *argv[]) {
|
|
|
|
|
throws();
|
2015-04-28 14:31:55 +08:00
|
|
|
try {
|
|
|
|
|
unreachable(1);
|
|
|
|
|
} catch (int) {}
|
2014-01-07 06:27:43 +08:00
|
|
|
return 0;
|
|
|
|
|
}
|