hanchenye-llvm-project/clang/test/Profile
..
Inputs
README
c-avoid-direct-call.c
c-captured.c
c-counter-overflows.c
c-general.c
c-generate.c
c-indirect-call.c
c-linkage-available_externally.c
c-linkage.c
c-outdated-data.c
c-ternary.c
c-unprofiled-blocks.c
c-unprofiled.c
c-unreachable-after-switch.c
cxx-class.cpp
cxx-hash-v2.cpp
cxx-implicit.cpp
cxx-indirect-call.cpp
cxx-lambda.cpp
cxx-linkage.cpp
cxx-missing-bodies.cpp
cxx-rangefor.cpp
cxx-stmt-initializers.cpp
cxx-structors.cpp
cxx-templates.cpp
cxx-throws.cpp
cxx-virtual-destructor-calls.cpp
def-assignop.cpp
def-ctors.cpp
def-dtors.cpp
func-entry.c
gcc-flag-compatibility.c
objc-general.m
profile-does-not-exist.c
profile-summary.c

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.