search for: 066116

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

...ounter-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 &...

...t;> The current design of -fprofile-instr-generate has the same fundamental >> flaw >> as the old gcc's gcov instrumentation: it has contention on counters. >> A trivial synthetic test case was described here: >> http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066116.html >> >> For the problem to appear we need to have a hot function that is >> simultaneously executed >> by multiple threads -- then we will have high contention on the racy >> profile counters. >> >> Such situation is not necessary very frequent, but when...

Hi, The current design of -fprofile-instr-generate has the same fundamental flaw as the old gcc's gcov instrumentation: it has contention on counters. A trivial synthetic test case was described here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066116.html For the problem to appear we need to have a hot function that is simultaneously executed by multiple threads -- then we will have high contention on the racy profile counters. Such situation is not necessary very frequent, but when it happens -fprofile-instr-generate becomes barely usable du...

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

...rs 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: >>> &gt...