<div dir="ltr"><div>I think this is an example of something that is generally tricky to do. You are essentially interested in preserving information about instructions across transformation passes. This is generally achieved by analysis passes that transformations can either clobber or preserve. However, it seems like this isn't something you can re-compute.</div><div>If this is just a temporary hack that you want to implement to give you this information, I suppose you can either add a flag to the MachineInstr to mark it as a specific type of spill/reload you are interested in. Or perhaps add a SmallPtrSet to MachineFunctionInfo that would track the instructions you're interested in.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 9, 2021 at 12:36 PM Armand Behroozi <<a href="mailto:armandb@umich.edu">armandb@umich.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello,<div><br></div><div>Thank you for your response.</div><div><br></div><div>TargetInstrInfo::isStoreToStackSlot() does tell you if an instruction is a spill; but I'm only interested in a subset of spills. I'm trying to find a way to filter the other ones out.<br></div><div>I believe frame indices have been eliminated b/c I have been using "isStoreToStackSlotPostFE" and "hasStoreToStackSlot" to determine if an instruction is a spill. The pass I built is running at the end of preEmitPass2.<br></div><div><br></div><div>I want to test the efficacy of a technique for reducing the number of register spills/reloads, but it can only address a subset of them (cannot handle the case where virtual registers are live across function calls). I'm trying to quantify how big this subset is and if it's worth doing the project. </div><div><br></div><div>I'm able to identify the subset during the register allocation phase, but as spills/reloads are moved and hoisted, and new spill/reload instructions are created while others are deleted, I lose track of how many of these spills/reloads make it to the final code. This is important, b/c I want to look at the dynamic spill/reload count, not just the static count. </div><div><br></div><div>Thank you.</div><div><br></div><div>Regards,</div><div><br></div><div>Armand</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 9, 2021 at 10:49 AM Nemanja Ivanovic <<a href="mailto:nemanja.i.ibm@gmail.com" target="_blank">nemanja.i.ibm@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Doesn't TargetInstrInfo::isStoreToStackSlot() tell you if the instruction is a spill? Or are you looking to identify spill/reload instructions after frame indices are eliminated?<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 8, 2021 at 9:32 AM Armand Behroozi via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello,<div><br></div><div>I'm trying to identify which spill/reload instructions save/reload virtual registers that are live across function calls. In other words, if a virtual reg is spilled before a call, reloaded after, and live during the call, I want to remember it.</div><div><br></div><div>I've figured out how to determine if a virtual register has its live range across a call instruction: I use the "checkRegMaskInterference(VirtReg)" method. Then, if storeRegToStackSlot or loadRegFromStackSlot is called while there's regmask interference, I know that a spill/reload instruction was created as well and mark its MCInstrDesc as fitting my criteria.</div><div><br></div><div>The issue I'm facing is that I don't know how to propagate this information from the RegAlloc stage to the end of the codegen pipeline as instructions are frequently created and destroyed, so the instructions and their MCInstrDesc don't survive until the end of "addPreEmitPass2."</div><div><br></div><div>Any thoughts on how to tackle this challenge would be greatly appreciated.</div><div><br></div><div>Thank you.</div><div><br></div><div>Regards,</div><div><br></div><div>Armand Behroozi</div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>