<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Hey,</div><div class=""><br class=""></div>Using the labels will be a good proxy, relative location within the file, not so much.<div class="">You could also use the debug line info, but that’s probably overkill.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">-Quentin<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 1, 2020, at 2:57 PM, Armand Behroozi <<a href="mailto:armandb@umich.edu" class="">armandb@umich.edu</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Dear Quentin,<div class=""><br class=""></div><div class="">Thank you for taking the time to respond. This was really helpful.</div><div class=""><br class=""></div><div class="">One final question. Do you have any suggestions for how to map the counts viewed on the CFG after llc is run w/ pgo data to the original CFG? Would using the BB debug labels (i.e. %while.body.preheader201) be good enough here?</div><div class=""><br class=""></div><div class="">When running LLC w/ pgo data, a function of interest has its BB count go to 149 as opposed to 128 when no pgo data is used. When looking at the CFG manually, labelled basic blocks seem to be in similar locations but I'm unsure if I can rely on this.</div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Thank you.</div><div class=""><br class=""></div><div class="">Regards,</div><div class=""><br class=""></div><div class="">Armand</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 30, 2020 at 7:07 PM Quentin Colombet <<a href="mailto:qcolombet@apple.com" target="_blank" class="">qcolombet@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">Hi Armand,<div class=""><br class=""></div><div class="">You can print the frequency of the blocks at the machine level.</div><div class="">If that frequency comes from pgo, these numbers should be accurate.</div><div class=""><br class=""></div><div class="">Take a look at <span style="font-family:Menlo;font-size:11px" class="">-view-machine-block-freq-propagation-dags=fraction </span>for instance.</div><div class=""><br class=""></div><div class="">Then, you should be able to just use the assembly file annotation like you were doing.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">-Quentin</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 30, 2020, at 3:30 PM, Armand Behroozi via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">Hello,<div class=""><br class=""></div><div class="">How would people recommend using LLVM (if at all) to get the dynamic spill/reload count and total number of instructions for a program? Speed and efficiency are unimportant. I just want it to be correct.</div><div class=""><br class=""></div><div class="">I'm using a debug build of LLVM 12 "clang version 12.0.0" on an x86_64-unknown-linux-gnu cpu.<br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><b class=""><u class="">What I've tried:</u></b></div></div><div class=""><div class="">I thought I'd use llvm's pgo to get asm BB counts and then multiply by the number of static spills and reloads in each asm BB. <br class=""></div><div class=""><br class=""></div><div class="">LLC annotates lines in the assembly file that result in spills and reloads i.e.:</div><div class="">movq %rax, -24(%rsp) # 8-byte Spill<br class=""> movq -16(%rsp), %rax # 8-byte Reload<br class=""></div><div class=""><br class=""></div><div class="">I couldn't find a way to instrument asm BBs w/ pgo using LLC, so I'm doing it at the IR level like this:</div><div class="">clang -emit-llvm -gline-tables-only -O3 file1.c file1.bc</div><div class="">opt -pgo-instr-gen -instrprof file1.bc -o file1.prof.bc </div><div class="">clang -fprofile-instr-generate file1.prof.bc file2.prof.bc etc.</div><div class="">-run it-</div><div class="">llvm-profdata merge -output=pgo.profdata default.profraw</div><div class="">opt -pgo-instr-use -pgo-test-profile-file=pgo.profdata -load mypass file.bc</div><div class=""><br class=""></div><div class="">Where "mypass" iterates through all the IR BBs and prints out the label and block frequency info.</div><div class=""><br class=""></div><div class="">I've quickly realized that asm BBs don't directly correspond to IR BBs b/c the CFG changes during code generation. Although I've managed to make a mostly correct mapping between IR BBs and asm BBs using their debug labels, it's been kind of messy. For example:</div><div class="">There is the odd situation where I'll find 2 asm BBs with the same debug label w/ pgo counters to different memory addresses.</div></div><div class=""><br class=""></div><div class="">There are also other complications where the pgo CFG is different from the original CFG, so I'm not convinced this is the correct way to go about it.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><b class=""><u class="">What I thought I'd try next</u></b></div><div class="">I wanted to write a MachineFunctionPass that gets a BB's static spill/reload count and then inserts a function call to keep track of its execution frequency. The pass would be run after all CFG changes have been made. There's a comment in X86TargetMachine.cpp that says: </div><div class="">" </div><div class="">// The X86 Speculative Execution Pass must run after all control</div>// flow graph modifying passes.<div class="">"</div><div class="">This is in void X86PassConfig::addPreEmitPass2(), and I was going to add my pass here. Since the function call would clobber registers, I was going to either re-run register allocation or callee save all the registers the function would use.</div><div class=""><br class=""></div><div class="">Any help/feedback would be appreciated.</div><div class=""><br class=""></div><div class="">Thank you.</div><div class=""><br class=""></div><div class="">Regards,</div><div class=""><br class=""></div><div class="">Armand Behroozi</div></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class=""><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div>
</div></blockquote></div><br class=""></div></body></html>