forked from OSchip/llvm-project
0ed74d9634
Conceptually one of these loops is just a while-loop, but the actual code-gen is more complicated. We don't instrument all the different control flow edges to get accurate counts for each conditional branch, nor do I think it makes sense to do so. Instead, make the simplifying assumption that the loop behaves like a while-loop. Use the same branch weights for the first check for an empty collection as would be used for the back-edge of a while loop, and use that same weighting for the innermost loop, ignoring the possibility that there may be some extra code to go fetch more elements. llvm-svn: 204767 |
||
|---|---|---|
| .. | ||
| Inputs | ||
| README | ||
| c-attributes.c | ||
| c-counter-overflows.c | ||
| c-general.c | ||
| c-linkage-available_externally.c | ||
| c-linkage.c | ||
| c-outdated-data.c | ||
| cxx-class.cpp | ||
| cxx-linkage.cpp | ||
| cxx-throws.cpp | ||
| objc-general.m | ||
README
These are tests for instrumentation based profiling. This specifically means the -fprofile-instr-generate and -fprofile-instr-use driver flags. Tests in this directory should usually test both: - the generation of instrumentation (-fprofile-instr-generate), and - the use of profile data from instrumented runs (-fprofile-instr-use). In order to test -fprofile-instr-use without actually running an instrumented program, .profdata files are checked into Inputs/. The input source files must include a main function such that building with -fprofile-instr-generate and running the resulting program generates the same .profdata file that is consumed by the tests for -fprofile-instr-use. Even tests that only check -fprofile-instr-use should include such a main function, so that profile data can be regenerated as the .profdata file format evolves.