[PATCH] D34608: [AArch64] Increase CSR cost when defering use of CSR is preferred

Jun Bum Lim via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jun 29 10:47:08 PDT 2017


junbuml added inline comments.


================
Comment at: lib/CodeGen/RegAllocGreedy.cpp:2384-2390
+  // Conservatively, we try to increase the CSR cost only when all blocks in
+  // the live range have no call.
+  ArrayRef<SplitAnalysis::BlockInfo> UseBlocks = SA->getUseBlocks();
+  for (int i = 0, e = UseBlocks.size(); i < e; ++i)
+    for (auto &MI : *UseBlocks[i].MBB)
+      if (MI.isCall())
+        return BestCost;
----------------
wmi wrote:
> I don't see why the logic here is better than D32201. It will miss the motivational case we are targeting. For a long live range of a function argument, which crosses call in a cold bb, we want to increase the first time CSRCost so that regalloc can choose to split the long live range before and after the call in the cold bb and use non-CSR register in the places other than the cold bb. As a result shrinkwrapping will be unblocked because after the splitting there will be less or no CSR use inside of entry/exit.
> 
> 
Hi Wei,

This change was intended to make a process for the context-sensitive CSR cost model proposed in D27366. The case this change is targeting is different from D32201. I believe  we can do this change on top of D32201 or this change  can be treated  differently from D32201.

This change try to defer allocating CSR when we prefer not to use one in some context. For that I check if there is any user block which contain a call. If none of the blocks has call, then I said allocating a CSR is  not preferred in that context. Then I increase CSRCost based on the frequency of the entry block. 

Like D32201, this change encourage more shrink-wrapping. In my experiment with spec2006/astar, one of the hot function was shrink-wrapped as we discourage the first allocation of CSR for a LR which do not expand across any call.



https://reviews.llvm.org/D34608





More information about the llvm-commits mailing list