[llvm] [AArch64] Implement latency costs for loads (PR #201567)

[David Green via llvm-commits]

================
@@ -5055,8 +5054,59 @@ InstructionCost AArch64TTIImpl::getMemoryOpCost(unsigned Opcode, Type *Ty,
   if (CostKind == TTI::TCK_CodeSize || CostKind == TTI::TCK_SizeAndLatency)
     return LT.first;
 
-  if (CostKind != TTI::TCK_RecipThroughput)
-    return 1;
+  if (CostKind == TTI::TCK_Latency) {
+    // Latency doesn't make much sense for stores, so just return 1
+    if (Opcode == Instruction::Store)
+      return 1;
+    // We expect the load to become LT.first loads of type LT.second. The
+    // latency will be the latency of the last load plus the time it gets to get
+    // there, which will be the amount of other loads before that (i.e. total
+    // loads - 1). We get the latency from the SchedModel, and assume that the
+    // loads become the variant with unsigned integer offset.
+    unsigned Inst = 0;
+    if (LT.second.isScalableVector() ||
+        ST->useSVEForFixedLengthVectors(LT.second)) {
+      Inst = AArch64::LDR_ZXI;
+    } else if (LT.second.isVector() || LT.second.isFloatingPoint()) {
+      switch (LT.second.getSizeInBits()) {
+      case 8:
+        Inst = AArch64::LDRBui;
+        break;
+      case 16:
+        Inst = AArch64::LDRHui;
+        break;
+      case 32:
+        Inst = AArch64::LDRSui;
+        break;
+      case 64:
+        Inst = AArch64::LDRDui;
+        break;
+      case 128:
+        Inst = AArch64::LDRQui;
+        break;
+      default:
+        llvm_unreachable("Unexpected float or vector type");
+      }
+    } else {
+      switch (LT.second.getSizeInBits()) {
+      case 8:
+        Inst = AArch64::LDRBBui;
+        break;
+      case 16:
+        Inst = AArch64::LDRHHui;
+        break;
+      case 32:
+        Inst = AArch64::LDRWui;
+        break;
+      case 64:
+        Inst = AArch64::LDRXui;
+        break;
+      default:
+        llvm_unreachable("Unexpected integer type");
+      }
+    }
+    return (LT.first - 1) + SchedModel.computeInstrLatency(Inst);
----------------
davemgreen wrote:

The first I would think. We use an in-order cpu scheduling model to help in-order cores perform better scheduling where they need all the help they can get, we would not want to hurt that in general. The main optimization that uses Latency CostKinds through the cost model is the select opt pass, that is designed to help out-of-order cores who can speculatively execute a branch much quicker than they can a select. The tests showed that you needed to override the generic cpu for some of the select opt tests, which I am hoping we can avoid.

https://github.com/llvm/llvm-project/pull/201567