search for: __llvm_prf_names

Displaying 20 results from an estimated 36 matches for "__llvm_prf_names".

2017 Jun 27
2
My experience using -DLLVM_BUILD_INSTRUMENTED_COVERAGE to generate coverage
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, Jun 27, 2017 at 2:09 PM, Friedman, Eli <efriedma at codeaurora.org> > wrote: > >> On 6/27/2017 1:47 PM, Xinliang David Li wrote: >> >> >> &...
2017 Jun 27
2
My experience using -DLLVM_BUILD_INSTRUMENTED_COVERAGE to generate coverage
...>> versions of count, not, FileCheck, etc. > > I tried looking into this a bit more. It looks like the profile > data file generated by llc contains approximately 5MB of counters > (__llvm_prf_cnts), 10MB of "data" (__llvm_prf_data), and 70MB of > __llvm_prf_names. __llvm_prf_data and __llvm_prf_names contain > which can be read from the original binary, as far as I can tell. > The 80MB of data wouldn't be a big deal if it were just sitting on > disk... but we also erase the whole file and rewrite it from > scratch after we me...
2015 May 20
2
[LLVMdev] why is coverage map and profile names mixed?
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: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150520/0c2cab1d/attachment.html>
2017 Jun 27
4
My experience using -DLLVM_BUILD_INSTRUMENTED_COVERAGE to generate coverage
...2-coverage-R at 2/llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp.html#L512> > On Jun 27, 2017, at 2:40 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > > I get a bunch of unreadable binary. Output piped to "less": > > String dump of section '__llvm_prf_names': > [ 2] #<CA>^Ex<DA><D4>is<E3>(^Z<EF>^O<DD>^P<A9><D5><F7><9B><CB><FB><A8>d<97>^U<96>O<9F><89><FB><85>AQ<B4>M<B5><B6>&)Wy~<FD>C^B\<B0>/$&...
2017 Jun 27
3
My experience using -DLLVM_BUILD_INSTRUMENTED_COVERAGE to generate coverage
...check" a bit by using non-instrumented versions > of count, not, FileCheck, etc. I tried looking into this a bit more. It looks like the profile data file generated by llc contains approximately 5MB of counters (__llvm_prf_cnts), 10MB of "data" (__llvm_prf_data), and 70MB of __llvm_prf_names. __llvm_prf_data and __llvm_prf_names contain which can be read from the original binary, as far as I can tell. The 80MB of data wouldn't be a big deal if it were just sitting on disk... but we also erase the whole file and rewrite it from scratch after we merge profile counters. Can we d...
2017 Jul 25
2
PGO, zlib and 'default.profraw'
...with ‘zlib’ enabled or ‘zlib’ disabled. On Windows with VS2015 there is no ‘zlib’. But I think that there is something different causing the problem, possibly in the linking. When profiling instrumentation is enabled, there are 4 new sections introduced: __llvm_prf_cnts __llvm_prf_data __llvm_prf_names __llvm_prf_vnds Since our target is an heterogeneous multi-core embedded system, it requires the use of some elaborate linking techniques, and the LD scripts are carefully crafted for this purpose. We use ‘ld’ from Binutils v2.28. However, I do not know what these new sections mean to ‘llvm-...
2017 Jun 19
3
My experience using -DLLVM_BUILD_INSTRUMENTED_COVERAGE to generate coverage
...mar wrote: >> My experience: >> >> 1. You have to specify -DLLVM_USE_LINKER=gold (or maybe lld works; I >> didn't try). If you link with binutils ld, the program will generate >> broken profile information. Apparently, the linked binary is missing >> the __llvm_prf_names section. This took me half a day to figure out. >> This issue isn't documented anywhere, and the only error message I >> got was "Assertion `!Key.empty()' failed." from llvm-cov. > > I expect llvm-cov to print out "Failed to load coverage: <reason>...
2017 Jul 18
4
PGO, zlib and 'default.profraw'
...improve the error message here? We should be able to check zlib::isAvailable and give an error like "profile uses zlib compression but the profile reader was built without zlib support" or so in this case. Xinliang David Li via llvm-dev <llvm-dev at lists.llvm.org> writes: > The __llvm_prf_names section is compressed but your llvm-profdata tool is > probably not built with zlib enabled. > > To disable compression, use option -mllvm -enable-name-compression=false > in your instrumentation build. > > David > > On Tue, Jul 18, 2017 at 7:05 AM, ORiordan, Martin via llv...
2017 Jul 18
2
PGO, zlib and 'default.profraw'
...e here? We should be able to check > zlib::isAvailable and give an error like "profile uses zlib compression but > the profile reader was built without zlib support" or so in this case. > > Xinliang David Li via llvm-dev <llvm-dev at lists.llvm.org> writes: > > The __llvm_prf_names section is compressed but your llvm-profdata tool > > is probably not built with zlib enabled. > > > > To disable compression, use option -mllvm > > -enable-name-compression=false in your instrumentation build. > > > > David > > > > On Tue, Jul 18, 2...
2017 Jun 17
3
My experience using -DLLVM_BUILD_INSTRUMENTED_COVERAGE to generate coverage
...ood test to figure out how mature it is, so I gave it a shot. My experience: 1. You have to specify -DLLVM_USE_LINKER=gold (or maybe lld works; I didn't try). If you link with binutils ld, the program will generate broken profile information. Apparently, the linked binary is missing the __llvm_prf_names section. This took me half a day to figure out. This issue isn't documented anywhere, and the only error message I got was "Assertion `!Key.empty()' failed." from llvm-cov. 2. The generated binaries are big and slow. Comparing to a build without coverage, llc becomes 8x lar...
2015 Feb 10
3
[LLVMdev] Coverage mapping issue: Malformed profile data
...4|int main() { 1| 5| return 0; 1| 6|} As far I can understand issue somehow related to unused static functions. Also, as I can track down the problem raised because of lib/ProfileData/CoverageMappingReader.cpp (SectionData::get) expects that function's names located inside __llvm_prf_names section but it not true in case of test1.c, instead some function names located inside .rodata section. Is it known issue? any hints, how to avoid or workaround it? -- Be happy, Best regards, Dmitry Volyntsev
2017 Dec 20
2
Question about : lprofValueProfNodes
...ent PGO and code coverage on a system that does not exit and does not have any file io, or any of stdc libraries that libclang-profile is using. (more like a kernel) So what I’m trying to do is instead of calling __llvm_profile_write_file () from the application, read the sections __llvm_prf_data, __llvm_prf_names, __llvm_prf_cnts and __llvm_prf_vnds after the critical tasks are done and transfer them to outside of the system. Then dump these sections in a char * array in a c file and attribute them to be in the associated section. Then compile that file with –u__llvm_profile_runtime to create an executable...
2014 Feb 21
12
[LLVMdev] asan coverage
> > > > We may need some additional info. What kind of additional info? > I haven't put a ton of thought into > this, but I'm hoping we can either (a) use debug info as is or add some > extra (valid) debug info to support this, or (b) add an extra > debug-info-like section to instrumented binaries with the information we > need. > I'd try this data
2018 Mar 13
1
Profiling Support for BareMetal Target
...made changes in the LCF to mimic Linux Platform (for linker magic) In data section i have added: __start___llvm_prf_cnts = .; KEEP(*(__llvm_prf_cnts)) __stop___llvm_prf_cnts = .; __start___llvm_prf_data = .; KEEP(*(__llvm_prf_data)) __stop___llvm_prf_data = .; __start___llvm_prf_names = .; KEEP(*(__llvm_prf_names)) __stop___llvm_prf_names = .; __start___llvm_prf_vnds = .; KEEP(*(__llvm_prf_vnds)) __stop___llvm_prf_vnds = .; 2. Since there are not .ctors or atexit available i called the functions lprofSetupValueProfiler and __llvm_profile_initialize_file from...
2017 Dec 20
2
Question about : lprofValueProfNodes
...on a system that does > not exit and does not have any file io, or any of stdc libraries that > libclang-profile is using. (more like a kernel) > So what I’m trying to do is instead of calling __llvm_profile_write_file > () from the application, read the sections __llvm_prf_data, > __llvm_prf_names, __llvm_prf_cnts and __llvm_prf_vnds after the critical > tasks are done and transfer them to outside of the system. > > > You may already have worked this out, but for completeness I'll mention > that this is typically done by: > 1. Allocating a buffer big enough to contain a...
2015 Sep 04
4
RFC: Reducing Instr PGO size overhead
...prevent those apps from being successfully linked c) Large raw profile dumps may also cause problems, e.g. running out of space. It can also profile bootstrap build really slow. Looking at various sources of size increase caused by instrumentation, it is clear that the biggest contributor is the __llvm_prf_names section. The current PGO implementation uses function assembly names as the lookup keys in the indexed format so it needs to be emitted in both rodata of the binary and in the raw/indexed profiles. On the other hand, LLVM's indexed format also supports 'key collision' -- it allows fun...
2017 Jul 18
3
PGO, zlib and 'default.profraw'
We are trying to get PGO working for our embedded out-of-tree target, but the utility 'llvm-profdata' does not like the data we are giving it. Because this is not a hosted environment, we have to off-chip the profiling data ourselves, and although the data looks okay, 'llvm-profdata' reports the following error: llvm-profdata show -all-functions -counts -detailed-summary -text
2017 Sep 06
5
Using source-based code coverage on baremetal
...ert code somewhere to write out the profile data yourself.  We used __llvm_profile_get_size_for_buffer() and __llvm_profile_write_buf() for this (and semihosting APIs to transfer the resulting buffer to the host). 3. Then, you have to edit your linker script to include the necessary sections.  __llvm_prf_names, __llvm_prf_data, and __llvm_prf_cnts need to be included in the final image.  And __llvm_covmap needs to be in a non-allocatable section in the ELF output.  And depending on how your linker behaves, you might need to explicitly mark all of these sections KEEP so parts don't get dropped.  T...
2019 Jan 24
2
答复: 答复: How to add new arch for llvm-cov show?
...llvm-cov so I thought it was MC provide this e_machine information to compiler). 2. New error was “Failed to load coverage: No coverage data found” since the compiler cannot get NamesSection(at loadBinaryFormat in CoverageMappingReader.cpp). I thought it was my ldscript problem because I put __llvm_prf_names, __llvm_prf_cnts, __llvm_prf_data and __llvm_prf_vnds inside .rodata section. Compiler checked .rodata but not things inside .rodata. What’s the right position to put these 4 __llvm_prf_* sections? Best, Ruobin. 发件人: vsk at apple.com [mailto:vsk at apple.com] 代表 Vedant Kumar 发送时间: 2019年1月24日 0:12...
2017 Jul 01
7
[RFC] Placing profile name data, and coverage data, outside of object files
...needed to run "clang -help" with an SSD: 0.5 seconds * Size of the clang binary: 725.24 MB * Space wasted on duplicate name/coverage data (*.o + *.a): 923.49 MB - Size contributed by __llvm_covmap sections: 1.02 GB \_ Just within clang: 340.48 MB - Size contributed by __llvm_prf_names sections: 327.46 MB \_ Just within clang: 106.76 MB => Space wasted within the clang binary: 447.24 MB Running an instrumented clang binary triggers a 143MB raw profile write which is slow even with an SSD. This problem is particularly bad for frontend-based coverage because it gener...