[LLVMdev] asan coverage
kcc at google.com
Tue Feb 18 03:13:09 PST 2014
Regarding performance, I've made a simple coverage with counters and
compared it with AsanCoverage.
AsanCoverage produces code like this:
je 48b4a0 # to call __sanitizer_cov
callq 4715b0 <__sanitizer_cov>
A simple counter-based thing (which just increments counters and does
nothing else useful) produces this:
The performance is more or less the same, although the issue with false
sharing still remains
Do you have any more details about the planned clang coverage?
On Tue, Feb 18, 2014 at 1:00 PM, Kostya Serebryany <kcc at google.com> wrote:
> On Tue, Feb 18, 2014 at 12:20 AM, Bob Wilson <bob.wilson at apple.com> wrote:
>> On Feb 17, 2014, at 5:13 AM, Kostya Serebryany <kcc at google.com> wrote:
>> > Then my question: will there be any objection if I disentangle
>> AsanCoverage from ASan and make it a separate LLVM phase with the proper
>> clang driver support?
>> > Or it will be an unwelcome competition with the planned clang coverage?
>> I don’t view it as a competition, but assuming that we both succeed in
>> our plans, LLVM would then end up with two very similar solutions for code
>> coverage. Does it really make sense to have two?
> It depends. If the two will indeed have the same functionality -- then no.
> My understanding about your plans is that the upcoming coverage will
> provide "counters" (== how many times a bb/edge was executed).
> AsanCoverage produces booleans (== 1, iff a function/bb was executed),
> which is less information, but faster.
> How much faster -- I can't tell w/o your performance numbers.
> For our early users the performance is critical and booleans are
> If we end up needing both variants, we may want to keep them similar from
> user perspective, e.g. have flag combinations like these:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev