similar to: Adding support for LLVM Branch Condition Coverage

+ Vedant Hi Hal, thanks. I apologize if my answers aren't as thorough as you would like; what I'm proposing is simply an extension to the existing infrastructure, so it would be enabled automatically as part of code coverage. Mapping of branch regions would be done in CoverageMappingGen and instrumented using the same profiling instrumentation mechanism under

Hi, Alan Thanks for making it clear. But I was more confused now :( I tested on a simple program and used both gcov and lcov to get branch coverage. The code and build commands as below: *Example simple.cc* #include <string> // If not comment this line, the branch coverage won't reach to 100% // #include <iostream> int main(int argc, const char* argv[]) { std::string str =

Hi, Alan Really very excited to receive your email and sorry to be slow replying, it has been exceptionally busy over the last few days ;( Your explanation made the problem clear to me. So gcov branch coverage should be called condition coverage and clang region coverage is branch coverage in fact(also known as *decision/C1*), right? And llvm/clang will support all the following coverage

Hi, llvm/clang experts I need to get the branch coverage for some testing code. But i found gcov can't give a expected coverage which may count some 'hidden branch' in (See stackoverflow answer <https://stackoverflow.com/questions/42003783/lcov-gcov-branch-coverage-with-c-producing-branches-all-over-the-place>). Instead, I turn to use clang and the 'source-based code

## TL;DR We introduce bcov, an open-source binary-level coverage analysis tool [1]. The details are discussed in our paper [2], which is accepted to ESEC/FSE'20. bcov statically instruments x86-64 ELF binaries without compiler support. It features several techniques that allow it to achieve high performance, transparency, and flexibility. For example, running "make

Updated set of patches for coverage. Changes: - change copyright lines - use gcov: instead of cover: in commit comment - use #ifdef in xen/common/sysctl.c instead of dummy inline function - added base documentation in docs/misc - added -h option to xencov

On Feb 12, 2014, at 10:31 AM, Kostya Serebryany <kcc at google.com> wrote: > Hi, > > Justin is making nice commits for llvm-cov, so I thought we may continue this discussion now. > The quick-and-dirty implementation of coverage (in asan) is getting some early users and they seem to be happy. > AsanCoverage allows to collect per-function or per-basic-block coverage

On Feb 12, 2014, at 11:43 PM, Kostya Serebryany <kcc at google.com> wrote: > > > > On Thu, Feb 13, 2014 at 11:10 AM, Bob Wilson <bob.wilson at apple.com> wrote: > > On Feb 12, 2014, at 10:31 AM, Kostya Serebryany <kcc at google.com> wrote: > >> Hi, >> >> Justin is making nice commits for llvm-cov, so I thought we may continue this

Hello, Our goals for the code coverage BoF (10/19) were to find areas where we can improve the coverage tooling, and to learn more about how coverage is used. I'd like to thank all of the attendees for their input and for making the BoF productive. Special thanks to Mandeep Grang, who volunteered as a mic runner at the last minute. In this email I'll share my (rough) notes and outline

Bob, Justin, I've just committed a poor man's coverage implementation that works with asan. http://llvm.org/viewvc/llvm-project?rev=194701&view=rev http://llvm.org/viewvc/llvm-project?rev=194702&view=rev It provides only function-level boolean coverage (i.e. no counters, just "visited or not"), but is very fast and very simple (no extra sections to the binary file, etc)

Hi Dean, We didn't discuss using XRay instrumentation during the BoF but it is an interesting idea (by the way, thanks for your talk about XRay internals!). XRay provides the advantage of being able to turn profiling on and off, but I'm not sure how the resulting data could be used. The code coverage feature is highly dependent on the frontend's profile counter placement. The mapping

Hi Not sure if this is a clang or llvm related question so I'm sending to both mailing lists. Anyways, I have few questions regarding size and execution time of instrumented code: We are trying to run code coverage on memory limited hardware and investigating both (generating gcov output using -coverage and the llvm's own way using -fprofile-instr-generate -fcoverage-mapping clang flags)

Hello, The following patch series enables LLVM coverage support for the Xen hypervisor. This first patches are a re-organization of the gcov support, in order to make the support generic for all coverage technologies. This is mostly a name change from gcov -> cov in several places and files, together with the addition of a Kconfig option in order to enable LLVM coverage. Patch 7 introduces

Hi Fangrui, Many thanks for providing such detailed feedback! Please find my comments inlined below. - Ammar On Sun, Jun 28, 2020 at 5:59 AM Fangrui Song <maskray at google.com> wrote: > On 2020-06-26, Ammar Ben Khadra via llvm-dev wrote: > >## TL;DR > > > >We introduce bcov, an open-source binary-level coverage analysis tool [1]. > >The details are discussed

With llc, the size of the names section can vary widely depending on the value of -DLLVM_TARGETS_TO_BUILD. Enabling coverage shouldn't increase the name section size much. I only see one place where this happens, and it's relatively cold: http://lab.llvm.org:8080/coverage/coverage-reports/llvm/coverage/Users/buildslave/jenkins/sharedspace/clang-stage2-coverage-R at

+ Evgeny We have a jump threading pass downstream for this that we would love to upstream. I believe Evgeny was working on exactly this, i.e. preparing it for upstreaming. ________________________________ From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Eli Friedman via llvm-dev <llvm-dev at lists.llvm.org> Sent: 23 September 2020 19:16 To: Phipps, Alan <a-phipps

Hi Sjoerd We (at Huawei) also have a pass for this. Originally we implemented this back in 2018 and meant to upstream it, but there were some issues with the implementation that required some changes in the code. We started revising it,a few weeks ago. I thought now that there are multiple options, maybe we can discuss our approaches, and see if there is a preference in the community for one

I had an old build of llc with FE instrumentation, the name section size is about 5MB. Using coverage is likely to cause the name section to be larger as there are more references to dead/unused function names. What do you see when readelf --string-dump=__llvm_prf_names llc David On Tue, Jun 27, 2017 at 2:23 PM, Xinliang David Li <davidxl at google.com> wrote: > > > On Tue,

It is my understanding that the implementation for jump-threading in LLVM is not presently able to effectively optimize code containing a state-machine implemented using a loop + switch. This is the case, for example, with the Coremark benchmark function core_state_transition(). Bug 42313 was filed to address this in 2019: https://bugs.llvm.org/show_bug.cgi?id=42313 It appears that GCC

Hi Justin , Thank you for the confirmation and we would like to know that ,going forward the clang has the support the gcc gcov format or use the -fprofile-instr-generate -fcoverage-mapping and get ride of gcov format . We are planing to customize the clang code coverage for embedded world ,before we start tweaking the gcov / -fprofile-instr-generate code-base ,we would like to take feedback