[llvm] [AArch64] Implement latency costs for loads (PR #201567)
John Brawn via llvm-commits
llvm-commits at lists.llvm.org
Wed Jun 10 08:02:09 PDT 2026
================
@@ -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);
----------------
john-brawn-arm wrote:
> The generic CPU is meant to be a middle-ground that gives the best result across many cpus. From the look of the test updates that might not be remaining true. Can you override it to a give a middle-ground latency?
By "it" do you mean this specific function or the scheduling model in general? For the first it would mean the load latency is inconsistent between different parts of the compiler, which I'm not a fan of. For the second it would I think require adding a scheduling model for the generic cpu, instead of just using the a510 one.
https://github.com/llvm/llvm-project/pull/201567
More information about the llvm-commits
mailing list