[cfe-dev] Support for selectively enabling profile instrumentation only for certain files/functions

Petr Hosek via cfe-dev cfe-dev at lists.llvm.org
Tue Mar 31 15:31:13 PDT 2020


We'd like to implement support for selectively enabling profile
instrumentation only for certain files/functions.

The motivation is collecting code coverage information in presubmit
testing, where we want to avoid instrumenting the entire build which would
introduce a lot of overhead. Rather, we only want to instrument
files/functions that were modified by the patch by passing this information
to Clang.

Clang already has -fprofile-filter-files= and -fprofile-exclude-files=, but
those flags are currently only supported by GCOV. Furthermore, they only
work at the granularity of entire files. I'm also not a fan of using flags
which increases the size of the command line as you keep adding more files.

The solution I'm considering for source-code coverage is use the special
case list (see
https://github.com/llvm/llvm-project/blob/master/llvm/include/llvm/Support/SpecialCaseList.h)
which
is already used by sanitizers and XRay and seems like a great fit for this
case. Concretely, we would add a new flag, e.g.
-fprofile-flter=path/to/special/case/list. The file would have the
following format:

[include]
src:src:/path/to/source/*
fun:MyFooBar
[exclude]
src:src:/path/to/source/file.c

This is similar to https://clang.llvm.org/docs/SanitizerSpecialCaseList.html
 and https://llvm.org/docs/XRay.html#special-case-file.

Does this sound reasonable?

Related question is whether this option should apply to both AST and IR
based instrumentation and where to perform the filtering. We could do the
filtering either when inserting the instrumentation instructions, i.e. in
PGOInstrumentation.cpp and CodeGenPGO.cpp, or when lowering these
instructions InstrProfiling.cpp (where we would just discard these
instructions). The advantage of the latter approach is that we only need to
implement the filtering once and it'd support both AST and IR based
instrumentation, but it also means that we would unnecessarily insert extra
instructions only to drop them later.

Does anyone have any preference or suggestion?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200331/4d247dbf/attachment.html>


More information about the cfe-dev mailing list