search for: instrprofile

Hi I'm referencing the method: Lib/Transforms/Instrumentation/InstrProfiling.cpp:InstrProfiling::lowerCoverageData() At the end of the function, why is the variable being placed in __llvm_prf_names section? Shouldn't it be placed in __llvm_covmap section? Thanks Ali -------------- next part -------------- An HTML attachment was scrubbed... URL:

...y that includes readers and writers for various profiling formats. Notably, (B) would make it a good place for a sample based profile reader, which currently lives in lib/Transforms with its usage. - If we go with (A), a name like Profile may be too generic, so something more specific like InstrProfile might be better. For (B), Profile or ProfileData seem best. The other part of the problem, (3), has no precedent that I'm aware of. Is there a way to include llvm libraries in compiler-rt that wouldn't cause problems? I don't plan on addressing this in the near future, but comments o...

Hi all, I think using code coverage on baremetal has come up once or twice on llvmdev, but I don't think anyone has actually written up how the workflow works, or what issues come up.  This description is based on work done together with my colleague Weiming Zhao. By "baremetal" here, I mean an embedded environment without an operating system.  We specifically used a ARM target

On Thu, Jan 17, 2019 at 2:47 PM Xinliang David Li <davidxl at google.com> wrote: > > > On Thu, Jan 17, 2019 at 2:32 PM Manman Ren <manman.ren at gmail.com> wrote: > >> >> >> On Thu, Jan 17, 2019 at 10:53 AM Xinliang David Li <davidxl at google.com> >> wrote: >> >>> Hi Manman, >>> >>> Ordering profiling is

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

Hi all! It seems I came across on issue with coverage mapping (http://www.llvm.org/docs/CoverageMappingFormat.html) check on: llvm revision: r228136 clang Last Changed Rev: 228121 build: Debug+Asserts OS: ubuntu 14.04 Here is simple snippets test1.c: NOT OK ================== #include <stdio.h> static int foo() { return 42; } int main() { return 0; } ================== cp src/test1.c

On Thu, Jan 17, 2019 at 10:53 AM Xinliang David Li <davidxl at google.com> wrote: > Hi Manman, > > Ordering profiling is certainly something very useful to have to startup > time performance. GCC has something similar. > > In terms of implementation, it is possible to simply extend the edge > profiling counters by 1 for each function, and instrument the function to >

I think that this proposal would be very useful, and I will describe our experiences of trying to do this for our embedded bare-metal target. Recently we implemented support for just the '-fprofile-instr-generate' option and the 'compiler-rt/lib/profile' sources, and added the following to our LD scripts: /* Append the LLVM profiling sections */ . = ALIGN(4);

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,

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

Kostya Serebryany <kcc at google.com> writes: > Justin, > Calling appendToUsed has horrible complexity and if we call it in > every function clang consumes tons of memory (6Gb when compiling one > of the clang's source files). This killed my machine today :) > > The solution is to call appendToUsed once per module, instead of once > per function. Oh right,

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

On Thu, Aug 24, 2017 at 6:30 PM, Justin Bogner <mail at justinbogner.com> wrote: > Peter Collingbourne <peter at pcc.me.uk> writes: > > On Thu, Aug 24, 2017 at 3:38 PM, Kostya Serebryany <kcc at google.com> > wrote: > > > >> > >> > >> On Thu, Aug 24, 2017 at 3:35 PM, Peter Collingbourne <peter at pcc.me.uk> > >> wrote:

llvm[4]: Compiling PoolAllocate.cpp for Release+Asserts build /home/NIKHILREDDY/WORK/LLVM_SRC/projects/poolalloc/lib/PoolAllocate/PoolAllocate.cpp: In member function ‘virtual bool llvm::PoolAllocate::runOnModule(llvm::Module&)’: /home/NIKHILREDDY/WORK/LLVM_SRC/projects/poolalloc/lib/PoolAllocate/PoolAllocate.cpp:403:16: error: ‘class llvm::Constant’ has no member named