[PATCH] D105284: Greedy set cover implementation of `Merger::Merge`
Matt Morehouse via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Sep 3 13:58:20 PDT 2021
morehouse added inline comments.
================
Comment at: compiler-rt/lib/fuzzer/tests/FuzzerUnittest.cpp:953
+ "",
+ true));
+ EXPECT_EQ(M.SetCoverMerge(Features, &NewFeatures, Cov, &NewCov, &NewFiles),
----------------
arisKoutsou wrote:
> morehouse wrote:
> > IIUC, this test doesn't quite do what's intended.
> >
> > We choose input C because it has the most unique features, but after that A only has `{0}` as a unique feature while B has `{4, 5}`. So we do in fact choose B, but not because it is smaller.
> Correct, I will adjust the features correctly so that we can test breaking ties between files with equal number of features.
The comment above is confusing me now. I *think* what's happening is that B is picked first (over A since B is smaller), leaving A with `{0, 3}` unique features and C with `{1, 2, 4}` unique features. Then C gets picked since it has more features.
We still end up with C and B in the set, but the comment's explanation of how this happens is wrong.
================
Comment at: compiler-rt/test/fuzzer/set_cover_merge.test:48
+CHECK_OVERLAP: MERGE-OUTER: 10 files, 1 in the initial corpus
+CHECK_OVERLAP: MERGE-OUTER: 2 new files with 6 new features added
+# Make sure that we are prefering smaller files (T3/3 over T3/a).
----------------
arisKoutsou wrote:
> morehouse wrote:
> > I think we would get the same results with `-merge`. Perhaps we should make some feature-poor inputs smaller so that `-merge` would pick those first, while `-set_cover_merge` picks the feature-rich ones.
> Should I also include a test of `-merge=1` in this source file to highlight the difference in behavior?
Yes, please do.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D105284/new/
https://reviews.llvm.org/D105284
More information about the llvm-commits
mailing list