search for: u__llvm_profile_runtim

...the size of the `__llvm_prf_data` section in > the object file containing the code that is later missing branch > weights. It looks like the GNU linker loses the `__llvm_prf_data` > section from that object file? > > > Also check the arguments passed to the linker. It should have -u__llvm_profile_runtime to force the profile runtime to be linked in. > > `-u__llvm_profile_runtime` is properly passed to the linker, > regardless of which linker it is. > > On Mon, Sep 16, 2019 at 7:40 PM Xinliang David Li <xinliangli at gmail.com> wrote: > > > > Can you clarify if perf...

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 has already come out of this: I > confirmed that `rustc` indeed uses `-ffunction-sections` and &...

...>> > the object file containing the code that is later missing branch >> > weights. It looks like the GNU linker loses the `__llvm_prf_data` >> > section from that object file? >> > >> > > Also check the arguments passed to the linker. It should have -u__llvm_profile_runtime to force the profile runtime to be linked in. >> > >> > `-u__llvm_profile_runtime` is properly passed to the linker, >> > regardless of which linker it is. >> > >> > On Mon, Sep 16, 2019 at 7:40 PM Xinliang David Li <xinliangli at gmail.com> wrote...

...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 that calls __llvm_profile_write_file to dump my profraw data. Sofar, I’m able to do the mechanics but seems like something is going wrong because because fprofile-instr-use does not find profile data for the source files. Any suggestion? Thanks A From: <vsk at apple....

...needed? > > Once you have the buffer from step 3 on the host machine, you've got a > well-formed raw profile. You should be able to fwrite() it to e.g > 'default.profraw' and test that it's a valid profile with llvm-profdata. > > > Then compile that file with –u__llvm_profile_runtime to create an > executable that calls __llvm_profile_write_file to dump my profraw data. > > Sofar, I’m able to do the mechanics but seems like something is going > wrong because because fprofile-instr-use does not find profile data for the > source files. > > > What error a...

Hi This array is defined in compiler-rt: InstrProfilingValue.c but I can’t find where it is used? And the comment on it does not say much about why we need it either. Can someone explain why we need this and where it is used? /* A shared static pool in addition to the vnodes statically * allocated by the compiler. */ COMPILER_RT_VISIBILITY ValueProfNode

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