search for: function_entry_count

Functions in LLVM IR have a function_entry_count metadata that is attached in PGO compilation. By using the entry count together with the block frequency info, the compiler computes the profile count of call instructions based on which the hotness/coldness of callsites can be determined. Experiments have shown that using a higher threshold for ho...

...o approximate those inlining decisions, so it might not > be the end of the world to have some divergence). > > -- Sean Silva > > On Dec 12, 2017 5:02 PM, "Easwaran Raman via llvm-dev" < > llvm-dev at lists.llvm.org> wrote: > >> Functions in LLVM IR have a function_entry_count metadata that is >> attached in PGO compilation. By using the entry count together with the >> block frequency info, the compiler computes the profile count of call >> instructions based on which the hotness/coldness of callsites can be >> determined. Experiments have shown...

...old functions are ending up in the regular .text section instead of .text.unlikely. Since that is done much later than splitting and is based on profile counts, it must be the case that profile data is not being propagated to the split functions in some way - do you know offhand if they are getting function_entry_count prof metadata? The other thing we noticed is that the .text.unlikely section is also reducing significantly, so it seems like some of the already cold blocks are getting split - has anyone noticed that? Teresa > -Aditya > > ------------------------------ > *From:* vsk at apple.com &...

...not be the end of the world to have some divergence). >>> >>> -- Sean Silva >>> >>> On Dec 12, 2017 5:02 PM, "Easwaran Raman via llvm-dev" < >>> llvm-dev at lists.llvm.org> wrote: >>> >>>> Functions in LLVM IR have a function_entry_count metadata that is >>>> attached in PGO compilation. By using the entry count together with the >>>> block frequency info, the compiler computes the profile count of call >>>> instructions based on which the hotness/coldness of callsites can be >>>> det...

...ding up in the regular > .text section instead of .text.unlikely. Since that is done much later than > splitting and is based on profile counts, it must be the case that profile > data is not being propagated to the split functions in some way - do you > know offhand if they are getting function_entry_count prof metadata? > > > At the moment, entry counts are not propagated to the split functions. > This should explain the behavior you see. > Ok, it should be straightforward to add that, will take a look. > > > The other thing we noticed is that the .text.unlikely section is...

Hi everyone, As part of my work for Mozilla's Low Level Tools team I've implemented PGO in the Rust compiler. The feature is available since Rust 1.37 [1]. However, so far we have not seen any actual performance gains from enabling PGO for Rust code. Performance even seems to drop 1-3% with PGO enabled. I wonder why that is and I'm hoping that someone here might have experience

...gt;>>>> >>>>> -- Sean Silva >>>>> >>>>> On Dec 12, 2017 5:02 PM, "Easwaran Raman via llvm-dev" < >>>>> llvm-dev at lists.llvm.org> wrote: >>>>> >>>>>> Functions in LLVM IR have a function_entry_count metadata that is >>>>>> attached in PGO compilation. By using the entry count together with the >>>>>> block frequency info, the compiler computes the profile count of call >>>>>> instructions based on which the hotness/coldness of callsites can...

Dear Duncan, I am generating branch-weights annotated IR files as described in the documentation of LLVM, using profiling with instrumentation. http://clang.llvm.org/docs/UsersManual.html#profiling-with-instrumentation e.g. llvm-profdata merge -output=$(BENCH).profdata default.profraw > clang -S -emit-llvm -O3 -fprofile-instr-use=$(BENCH).profdata -o > bench.prof.ll bench.c The issue is

...bel %9 9: ; preds = %6, %4 %10 = phi i32 [ %1, %4 ], [ %8, %6 ] %11 = load i32, i32* @i, align 4 %12 = add nsw i32 %10, %11 store i32 %12, i32* @i, align 4 ret i32 %12 } declare i32 @L1() declare i32 @R1() cold nounwind !1 = !{!"function_entry_count", i64 7} !2 = !{!"branch_weights", i32 0, i32 7} ``` Code generated by Machine Function Splitter $ llc < example.ll -mtriple=x86_64-unknown-linux-gnu -split-machine-functions ``` .text .file "<stdin>" .globl foo...

The splitting pass currently doesn’t move cold symbols into a separate section. Is that affecting your results? On Darwin, we plan on using a symbol attribute to provide an ordering hint to the linker (see r352227, N_COLD_FUNC). vedant > On Jan 28, 2019, at 10:51 AM, Aditya K via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Very happy to see good results. On our side, we are

...%9 9: ; preds = %6, %4 %10 = phi i32 [ %1, %4 ], [ %8, %6 ] %11 = load i32, i32* @i, align 4 %12 = add nsw i32 %10, %11 store i32 %12, i32* @i, align 4 ret i32 %12 } declare i32 @L1() declare i32 @R1() cold nounwind !1 = !{!"function_entry_count", i64 7} !2 = !{!"branch_weights", i32 0, i32 7} ``` Code generated by Machine Function Splitter $ llc < example.ll -mtriple=x86_64-unknown-linux-gnu -split-machine-functions ``` .text .file "<stdin>" .globl foo...

...1 = load i32, i32* @i, align 4 >> >> %12 = add nsw i32 %10, %11 >> >> store i32 %12, i32* @i, align 4 >> >> ret i32 %12 >> >> } >> >> declare i32 @L1() >> >> declare i32 @R1() cold nounwind >> >> !1 = !{!"function_entry_count", i64 7} >> >> !2 = !{!"branch_weights", i32 0, i32 7} >> >> ``` >> >> Code generated by Machine Function Splitter >> >> $ llc < example.ll -mtriple=x86_64-unknown-linux-gnu >> -split-machine-functions >> >> ``` &gt...