[all-commits] [llvm/llvm-project] 9438c6: [AArch64] Fix load latency costs without a usable ...

[Tim Besard via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 9438c6f46ec922d81d4a98f0bab50ecbd27d4ead
      https://github.com/llvm/llvm-project/commit/9438c6f46ec922d81d4a98f0bab50ecbd27d4ead
  Author: Tim Besard <tim.besard at gmail.com>
  Date:   2026-09-16 (Wed, 16 Sep 2026)

  Changed paths:
    M llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp
    A llvm/test/Analysis/CostModel/AArch64/load-latency-fallback.ll

  Log Message:
  -----------
  [AArch64] Fix load latency costs without a usable scheduling class (#223416)

#201567 made AArch64TTIImpl::getMemoryOpCost query the scheduling model
for the latency of loads, but that information isn't always available:

* CPUs without a scheduling model (carmel, which uses NoSchedModel) call
getSchedClassDesc on a null table. This asserts with "No scheduling
machine model" and segfaults in release builds. It is reachable from
SelectionDAGBuilder::shouldKeepJumpConditionsTogether when compiling
functions with target-cpu=carmel.
* Invalid scheduling classes (integer loads on oryon-1, and LDR_ZXI on
the models without SVE when +sve is enabled) give a latency of 0 for
single loads and very large latencies for loads split into several.
* Variant scheduling classes (FP/vector loads on c1-nano, c1-premium and
c1-ultra) can't be resolved without an instruction and give the same
bogus values.

In these cases fall back to the default load latency of the scheduling
model, using the same formula as the fixed load latency path. CPUs whose
scheduling model describes the loads are unaffected.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications