The idea is to add two options to easily include/exclude some files from being instrumented. Here are two use cases: 1) -coverage-exclude=/usr/include/*: typically we remove the data for such files when post-processing the gcno/gcda so we don't need to instrument them and so we could reduce the overhead due to instrumentation. 2) -coverage-filter=.*/foo.cpp:.*/bar.cpp: here we want to only instrument these two files (for example, to display code coverage data for files appearing in a patch at review phase) These options could take regular expressions separated by colon to give more flexibility in the choice of the files. When the user is using both options only the files which match a regex in filter and don't match all of the regex in exclude are instrumented. I already proposed such a feature for clang: https://reviews.llvm.org/D52033 https://reviews.llvm.org/D52034 It would be nice to have the same feature for gcc (if it doesn't exist off course) with the same option names. What do you think ?
In general, I like the idea and I understand your motivation to reduce the overhead. I can probably work on that, but I'm not promising to deliver that to GCC 9.1.
About the name of the options -coverage-exclude & -coverage-filter, I took my inspiration from the gcovr (-gcov-exclude & -gcov-filter): https://manpages.debian.org/jessie/gcovr/gcovr.1.en.html @martin, are you ok with that or do you have other ideas ?
Well, in case of GCC, the option can be also used for -fprofile-{generate,use} in order to train and optimize just part of a program. I like names 'filter' and 'exclude', so maybe -fprofile-files-filter and -fprofile-files-exclude. I would like to ask Honza (profile use maintainer) what he's thinking about it?
Maybe the other way around: -fprofile-filter-files -fprofile-exclude-files
@martin, @honza: about option names, do we have an agreement on -fprofile-filter-files and -fprofile-exclude-files ?
from IRC: <honza> calixte: I think -fprofile-filter-files <honza> -fprofile-exclude-files <honza> as Martin proposes looks OK to me.
Good then, maybe I'll do that in next weeks. It should not be so difficult from implementation point of view.
Ok, I've got a patch prototype and I hope I'll be able to sent it before the end of this stage1. > The idea is to add two options to easily include/exclude some files from > being instrumented. > Here are two use cases: > 1) -coverage-exclude=/usr/include/*: typically we remove the data for such > files when post-processing the gcno/gcda so we don't need to instrument them > and so we could reduce the overhead due to instrumentation. > 2) -coverage-filter=.*/foo.cpp:.*/bar.cpp: here we want to only instrument > these two files (for example, to display code coverage data for files > appearing in a patch at review phase) However, calixte can you please explain me difference in between those two options. More precisely, one is a white list and the second one is a black list. Will you mix these together or they will be used exclusively?
(In reply to Martin Liška from comment #8) > Ok, I've got a patch prototype and I hope I'll be able to sent it before > the end of this stage1. > > > The idea is to add two options to easily include/exclude some files from > > being instrumented. > > Here are two use cases: > > 1) -coverage-exclude=/usr/include/*: typically we remove the data for such > > files when post-processing the gcno/gcda so we don't need to instrument them > > and so we could reduce the overhead due to instrumentation. > > 2) -coverage-filter=.*/foo.cpp:.*/bar.cpp: here we want to only instrument > > these two files (for example, to display code coverage data for files > > appearing in a patch at review phase) > > However, calixte can you please explain me difference in between those two > options. > More precisely, one is a white list and the second one is a black list. Will > you > mix these together or they will be used exclusively? Few things: i) I use ';' as regex separator (to avoid issues under windows with C:\...) ii) if exclude is empty and filename is matching any of the regexes in filter then instrument it. iii) if filter is empty and filename is not matching any of the regexes in exclude then instrument it. iv) if both are not empty and filename is matching any of the regexes in filter AND is not matching any of the regexes in exclude then instrument it. Few examples: i) exclude="^/usr/include/;^/usr/local/include/" => a file is instrumented if and only if it isn't in /usr/include/ nor in /usr/local/include/ ii) filter="^/home/foo/dev/.*\.cpp;^/home/foo/ved/.*\.cpp" => a file is instrumented if and only if it's a cpp file somewhere under /home/foo/dev/ or /home/foo/ved/ iii) exclude="^/usr/include/.*$" and filter="^/usr/.*$" => a file is instrumented if and only if it's somewhere under /usr/ but not under /usr/include My patch for llvm is here: https://reviews.llvm.org/D52033 If you see something wrong or have idea to improve, please ping me.
> > Few things: > i) I use ';' as regex separator (to avoid issues under windows with C:\...) > ii) if exclude is empty and filename is matching any of the regexes in > filter then instrument it. > iii) if filter is empty and filename is not matching any of the regexes in > exclude then instrument it. > iv) if both are not empty and filename is matching any of the regexes in > filter AND is not matching any of the regexes in exclude then instrument it. > > Few examples: > i) exclude="^/usr/include/;^/usr/local/include/" => a file is instrumented > if and only if it isn't in /usr/include/ nor in /usr/local/include/ > ii) filter="^/home/foo/dev/.*\.cpp;^/home/foo/ved/.*\.cpp" => a file is > instrumented if and only if it's a cpp file somewhere under /home/foo/dev/ > or /home/foo/ved/ > iii) exclude="^/usr/include/.*$" and filter="^/usr/.*$" => a file is > instrumented if and only if it's somewhere under /usr/ but not under > /usr/include > > My patch for llvm is here: > https://reviews.llvm.org/D52033 > > If you see something wrong or have idea to improve, please ping me. Looks good to me, I've just sent patch candidate: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00568.html
Author: marxin Date: Mon Nov 12 21:01:38 2018 New Revision: 266037 URL: https://gcc.gnu.org/viewcvs?rev=266037&root=gcc&view=rev Log: Instrument only selected files (PR gcov-profile/87442). 2018-11-12 Martin Liska <mliska@suse.cz> PR gcov-profile/87442 * common.opt: Add -fprofile-filter-files and -fprofile-exclude-files options. * doc/invoke.texi: Document them. * tree-profile.c (parse_profile_filter): New. (parse_profile_file_filtering): Likewise. (release_profile_file_filtering): Likewise. (include_source_file_for_profile): Likewise. (tree_profiling): Filter source files based on the newly added options. 2018-11-12 Martin Liska <mliska@suse.cz> PR gcov-profile/87442 * gcc.dg/profile-filtering-1.c: New test. * gcc.dg/profile-filtering-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/profile-filtering-1.c trunk/gcc/testsuite/gcc.dg/profile-filtering-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/common.opt trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-profile.c
Fixed on trunk.