[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