search for: __llvm_prf_

...le(Arch).getArch()” and it makes an error if not equal. “OF->getArch” will go into a switch/case and the code enters the default branch which returns an UnknownArch. I hacked the code to make default branch return Triple::XXXX(only a temporary solution for the first point). Where should I place __llvm_prf_* sections? Is it ok to put them into .rodata section? Best, Ruobin 发件人: vsk at apple.com [mailto:vsk at apple.com] 代表 Vedant Kumar 发送时间: 2019年1月25日 3:14 收件人: xuruobin <xuruobin at huawei.com> 抄送: llvm-dev at lists.llvm.org; Yuchao (Michael) <michael.yuchao at huawei.com> 主题: Re: [llv...

Interestingly, a C version of the same test program [1] compiled with Clang 8 does not have any problems with GNU ld: The `__llvm_prf_data` section is the same size for all three linkers. It must be something specific to the Rust compiler that's going wrong here. [1] https://github.com/michaelwoerister/rust-pgo-test-programs/tree/master/cpp_branch_weights On Tue, Sep 17, 2019 at 3:26 PM Michael Woerister <mwoerister at mo...

...in any event, they are both built 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...

Can you clarify if performance difference is caused by using different linkers at instrumentation build? If that is the case, try dump the sections of the resulting binary and compare __llvm_prf_** sections. Also check the arguments passed to the linker. It should have -u__llvm_profile_runtime to force the profile runtime to be linked in. David On Mon, Sep 16, 2019 at 8:42 AM Michael Woerister via llvm-dev < llvm-dev at lists.llvm.org> wrote: > So one interesting observation h...

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

...ere: https://bugs.llvm.org/show_bug.cgi?id=25286 > > On Tue, Sep 17, 2019 at 8:39 AM Michael Woerister <mwoerister at mozilla.com> wrote: >> >> Interestingly, a C version of the same test program [1] compiled with >> Clang 8 does not have any problems with GNU ld: The `__llvm_prf_data` >> section is the same size for all three linkers. It must be something >> specific to the Rust compiler that's going wrong here. >> >> [1] https://github.com/michaelwoerister/rust-pgo-test-programs/tree/master/cpp_branch_weights >> >> On Tue, Sep 17, 20...

Hi vedant, The program didn't pass the checking "OF->getArch() != Triple(Arch).getArch()" loadBinaryFormat in CoverageMappingReader.cpp and returned an error. It's because "OF->getArch()" returned null and "Triple(Arch).getArch()" returned XXXX(name of my arch). The returned value of " OF->getArch()" is decided by "

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

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

On Thu, Sep 12, 2019 at 8:18 AM Teresa Johnson <tejohnson at google.com> wrote: > I just have a couple suggestions off the top of my head: > - have you tried using the new pass manager > (-fexperimental-new-pass-manager)? That has access to additional analysis > info during inlining and is able to make more precise PGO based inline > decisions. > (although note the above