<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 28, 2016, at 12:59 PM, vivek pandya <<a href="mailto:vivekvpandya@gmail.com" class="">vivekvpandya@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I have been working on PGO driven IPRA and I want to measure if this help to reduce execution time. So as mentioned earlier the idea is to make cold function register usage free i.e saving and restoring all used register by such cold function so caller of that function will have more free registers. So here I am changing standard callee saved registers set to a set which will be decided dynamically based on the actual register usage.</div></div></blockquote><div><br class=""></div><div>Is it different from something like “preserve_all”?</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""> <div class="">I am facing few problems to get this working:</div><div class="">1 ) While generating CFI for such function it requires to map Dwarf register to LLVM register and even if we force LLVM to use Dwarf register number for CFI then also it will be wrong for some register for which currently we don't have such mapping for example R8D register on X86 (when dealing with actual register usage info we may have such case where R8D is being used)</div><div class="">To fix this I tried to filter the functions which will be optimized by putting a constraints that it should have attribute NoUnwind but that does not help. Is it possible to disable CFI generation?</div><div class=""><br class=""></div><div class="">2) R8D is a 48 bit register but pushing and popping such register is not allowed and current implementation for CalleeSaved Register also uses either 64 bit or 32 bit version of X86 instruction according to target. So here I think it may be good to push/pop R8 for R8D (i.e I don't want to change current implementation which inserts MI for CSR) for that I need to find biggest register for which given register is alias like R8 has R8D as alias. How can I find that? </div><div class="">I tried to use getMatchingSuperReg(unsigned Reg, unsigned SubIdx, const TargetRegisterClass *RC) but here I don't know what will be SubIdx for given Reg in given RC.</div></div></div></div></blockquote><div><br class=""></div><div>If you create a function with a “preserve_all” CC and put some inline assembly that clobbers r8d, I expect we’re already generating the correct push (outside of IPRA), right?</div><div>I’d start by figuring out how this work.</div><div><br class=""></div><div>— </div><div>Mehdi</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><br class=""></div><div class="">So for example if a function which should be optimized for above optimization is having following set of clobbered registers:</div><div class="">R8D,R8, ECX, EAX, RAX, ESI It should push/pop R8, RCX, RAX, RSI.</div><div class=""><br class=""></div><div class="">Please help!</div><div class="">- Vivek</div><div class=""> <br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, Jul 9, 2016 at 12:26 AM, vivek pandya <span dir="ltr" class=""><<a href="mailto:vivekvpandya@gmail.com" target="_blank" class="">vivekvpandya@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote"><span class="">On Sat, Jul 9, 2016 at 12:18 AM, Mehdi Amini <span dir="ltr" class=""><<a href="mailto:mehdi.amini@apple.com" target="_blank" class="">mehdi.amini@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Jul 8, 2016, at 11:41 AM, vivek pandya <<a href="mailto:vivekvpandya@gmail.com" target="_blank" class="">vivekvpandya@gmail.com</a>> wrote:</div><br class=""><div class=""><br class=""><br style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div class="gmail_quote" style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On Fri, Jul 8, 2016 at 11:46 PM, Mehdi Amini<span class=""> </span><span dir="ltr" class=""><<a href="mailto:mehdi.amini@apple.com" target="_blank" class="">mehdi.amini@apple.com</a>></span><span class=""> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Jul 8, 2016, at 11:12 AM, vivek pandya <<a href="mailto:vivekvpandya@gmail.com" target="_blank" class="">vivekvpandya@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><blockquote type="cite" style="color:rgb(80,0,80);font-size:13px" class=""><div dir="ltr" class="">Hello LLVM Developers,<div class=""><br class=""></div><div class="">I have a thought to improve IPRA and I would like summaries discussion on IRC regarding that so we can develop an idea out of that if it really helps.</div><div class=""><br class=""></div><div class="">So idea is to have more callee saved registers at infrequently called leaf procedures and try provide more registers to procedures which are in upper region of the call graph. But as pointed out by Quentin this optimization may help in context of "true" IPRA but in our case we may not require this. But I think that it can improve performance in current IPRA. I explain both arguments ( Quentin's and mine) with following example. </div><div class=""><br class=""></div><div class="">Consider following call sequence A->B->C , here C is very less time called leaf procedure while A is called frequently and B may call C based on some condition now while propagating actual register usage information from C to A we almost clobbered most of the registers so in this case as per Quentin's point we does not hurt the performance as we fall back to CC but I think we can improve the performance as follows:</div><div class="">If we mark every register preserved by C (i.e having more spill reloads at procedure entry and exit ) and if this can help at A. Suppose A requires more number of distinct registers than CC can provide and if not provided it will spill variables to memory. Now if we can provide more registers at A by having more spills at C then we can save spill at A which can be beneficial because A is frequently called but C is less frequently called and thus reducing total number of spill/restore in program execution.</div><div class=""><br class=""></div><div class="">However again effect of this optimization will be limited by the scope of current IPRA (i.e one Module only) because we can' really propagate the details about more callee saved registers to caller which is defined in other module, but still it may helpful.</div><div class=""><br class=""></div><div class="">Any thoughts on this ?</div></div></blockquote></div></div></blockquote><div class=""><br class=""></div><div class=""><br class=""></div></span><div class="">I think it is interesting, have you considered:</div><div class=""><br class=""></div><div class="">- the code size impact? (C will have a lot of spills) </div></div></div></blockquote><div class="">Yes, this needs to be address with some heuristics based on call frequency to C and no of clobbers it has. Also can we say that a function which does not have any kind of call instruction in it's body will have less clobbers ?</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">I am not sure what you mean.</div></div></div></blockquote></span><div class="">A function which may do lots of computation but does not required to call any other function may not have too many simultaneous live ranges thus with very few registers it can be compiled.</div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote" style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class="">- what if C is cold but all (most) of its call sites are located in different modules?</div></div></div></blockquote><div class="">Can we user Uses to get no of call site in current module and based on that we decide to optimize? Again some heuristics . </div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Of course, but what I’m mentioning is exactly what does not work with that. </div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote" style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class="">- an alternative approach where we would break the CGSCC ordering to codegen B and A before C, so we would be able to spill minimally when performing the codegen for C?</div></div></div></blockquote><span class=""><div class="">Do you here mean marking all preserve for C while code gen for B and then when we come to C (top-down) we may avoid some spills if C can use regs which are not really used by B?</div></span></div></div></blockquote><div class=""><br class=""></div><div class="">Yes, but it may be harder to implement for not much gain after all.</div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote" style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="">Also this can be applied to a function which is less frequently called and which may not be a leaf function. It may help. </div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Sure, you can just refer to this as “PGO driven IPRA”.</div></div></div></blockquote></span><div class="">Ok I will look into this.</div><div class=""><br class=""></div><div class="">Vivek </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class=""><br class=""></div>— </div><span class=""><font color="#888888" class=""><div class="">Mehdi</div><div class=""><br class=""></div></font></span></div></blockquote></div><br class=""></div></div>
</blockquote></div><br class=""></div></div></div></div>
</div></blockquote></div><br class=""></body></html>