search for: 4715b0

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-O...

...com> wrote: > > 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://list...

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

...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 fal...