<div dir="ltr">Dear community,<div><br></div><div>This is to brief you the progress of Interprocedural Register Allocation, for those who are interested to see the progress in terms of code please consider <a href="http://reviews.llvm.org/D20769">http://reviews.llvm.org/D20769</a> </div><div>This patch contains simple infrastructure to propagate register usage information of callee to caller in call graph. The code generation order is changed to follow bottom up order on call graph , Thanks to Mehdi Amini for the patch for the same !  I will write a blog on this very soon. </div><div><br></div><div>So during this week as per the schedule proposed it should be study related infrastructure in LLVM and finalizing an approach for IPRA, but instead I am able to implement a working (may not be fully correct) prototype because I have used community bonding period to discuss and learn related stuffs from the mentors and also due to patch for CodeGen reordering was provided by dear mentor Mehdi Amini.</div><div><br></div><div>So I conclude the work done during this week as follows:</div><div><div>Implementation :</div><div>============</div><div>Following passes have been implemented during this week:
An immutable pass to store competed RegMask, a  machine function pass that iterates through each registers and check if it is used or not and based on that details create a RegMask and a target specific machine function pass that uses the RegMask created by second pass and propagates information by updating call instructions RegMask. To update the RegMask of MI , setRegMask() function has been added to MachineOperand, a command line option -enable-ipra and debug type -debug-only=“ipra" has been added to control the optimization through llc.</div><div><br></div><div>Testing: </div><div>=====</div><div>The above mentioned implementation has been tested over SNU-Real-Time benchmark suit (<a href="http://www.cprover.org/goto-cc/examples/snu.html">http://www.cprover.org/goto-cc/examples/snu.html</a>) and some simple programs that uses library function ( for a library function register allocation is not done by LLVM so this optimization will simply skip them)<span class="" style="white-space:pre"> </span></div><div><br></div><div>Study and Other:</div><div>=============</div><div>I have learned following things in LLVM, how it stores reg clobbering information? how it is used by Reg allocators through LivePhysRegs, LiveRegMatrix and other related passes? How to schedule a pass using TargetPassConfig and TargetMachine? What are called callee saved registers? What is an Immutable Pass? 
Apart from that I have also learned how to use phabricator to send review request. 
I have also read some related literatures.<span class="" style="white-space:pre">      </span></div></div><div><br></div><div>During this week though task was to schedule the passes in proper order so that dependencies of related passes are satisfied.</div><div><br></div><div>Plan for next week:</div><div>1) Perform more testing and debug any known issue</div><div>2) Fine ture the implementation so as to eliminate any unnecessary work</div><div>3) During the testing from the stats I have observed that IPRA does not always improve the work of IntraProcedural register allocators and it is also observer that the amount of benefit (in terms of spilled live ranges ) is not deterministic. So I would like to find reasons for this behavior.</div><div>4) Start implementing target specific pass for other targets if review passes properly with no major bugs.</div><div><br></div><div>Please provide any feedback/suggestion including for format of this email. </div><div><br></div><div>I would also like to thanks my mentors Mehdi Amini , Hal Finkel, <span style="font-size:13px">Quentin Colombet, </span><span style="font-size:13px">Matthias Braun</span><span style="font-size:13px"> and other community members for providing quick help every time when I asked ( I have got replies even after 8 PM ( PDT) ! ) .</span></div><div><span style="font-size:13px"> </span></div><div>Sincerely,</div><div>Vivek</div></div>