When building with libFuzzer, simplifyCFG reduces the coverage signal
available to libFuzzer when trying to find new inputs. This patch
provides a way to disable simplifyCFG when building with libFuzzer.
Addresses https://llvm.org/pr36414.
Differential D43423
[SimplifyCFG] Create flag to disable simplifyCFG. morehouse on Feb 16 2018, 4:45 PM. Authored by
Details
When building with libFuzzer, simplifyCFG reduces the coverage signal Addresses https://llvm.org/pr36414.
Diff Detail
Event Timeline
Comment Actions Some high level comments:
FWIW, I'd very much prefer the details of the optimizer wouldn't be exposed as frontend flags.
Some alternatives which I don't like, but I can't currently propose anything better are:
Please note that completely disabling SimplifyCFG will result in non-trivial performance hits (at least, in my experience), so you might want to evaluate this carefully. Comment Actions We use function attributes in similar situations for asan/tsan/msan. IIRC, the *function* metadata is not that easily stripped (as opposed to metadata attached to instructions). Comment Actions We might not need the flag if we decide to always set no_simplify_cfg during codegen with coverage instrumentation. But we're not sure if we want to do that yet.
Should be simple enough to change this to a function attribute if you think that is more appropriate. Wasn't sure whether metadata or an attribute made more sense.
This seems like a lot more work.
This patch allows us to annotate our functions with no_simplify_cfg to do what you're suggesting. Writing another instrumentation pass seems like overkill.
We're still evaluating this with mixed results. On one hand, disabling simplifyCFG makes most of our libFuzzer tests pass with -O2, and libFuzzer seems to perform at the same executions/sec rate. On the other hand, executions/sec doesn't necessarily translate to more coverage/sec or bugs found.
Comment Actions
Yes, definitely this. Frontend flags to control the optimizer should state an expected result, not just turn off some completely arbitrary set of transforms. Otherwise, we're likely to end up in a situation in the future where we add a new optimization, or split an existing pass, and it isn't clear which transforms the frontend flag should apply to.
|
why metadata instead of cl:opt like these?