Regarding performance, I've made a simple coverage with counters and
compared it with AsanCoverage.
AsanCoverage produces code like this:
mov 0xe86cce(%rip),%al
test %al,%al
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:
incq 0xe719c6(%rip)
The performance is more or less the same, although the issue with false
sharing still remains
(http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066116.html)
Do you have any more details about the planned clang coverage?
Thanks,
--kcc
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
> sufficient.
>
> If we end up needing both variants, we may want to keep them similar from
> user perspective, e.g. have flag combinations like these:
> -coverage=per-edge,counter
> -coverage=per-function,counter
> -coverage=per-block,counter
> -coverage=per-function,boolean
> -coverage=per-block,boolean
>
> --kcc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140218/1d36dc48/attachment.html>