tryLatency compares two sched candidates. For the top zone it prefers the one with lesser depth, but only if that depth is greater than the total latency of the instructions we've already scheduled -- otherwise its latency would be hidden and there would be no stall. Unfortunately it only tests the depth of one of the candidates. This can lead to situations where the TopDepthReduce heuristic does not kick in, but a lower priority heuristic chooses the other candidate, whose depth *is* greater than the already scheduled latency, which causes a stall. The fix is to apply the heuristic if the depth of *either* candidate is greater than the already scheduled latency. All this also applies to the BotHeightReduce heuristic in the bottom zone. Differential Revision: https://reviews.llvm.org/D72392
17 lines
714 B
YAML
17 lines
714 B
YAML
# NOTE: Assertions have been autogenerated by utils/update_mir_test_checks.py
|
|
# RUN: llc -mtriple=x86_64 -enable-post-misched -run-pass=postmisched -o - %s | FileCheck %s
|
|
---
|
|
# Check that postmisched's TopDepthReduce heuristic moves the DEC32r later
|
|
# because of the dependency on eax
|
|
name: test
|
|
body: |
|
|
bb.0:
|
|
; CHECK-LABEL: name: test
|
|
; CHECK: $eax = MOV32rr killed $edi
|
|
; CHECK: MOV8mi killed renamable $rsi, 1, $noreg, 0, $noreg, 1 :: (store 1)
|
|
; CHECK: renamable $eax = DEC32r killed renamable $eax, implicit-def $eflags
|
|
$eax = MOV32rr $edi
|
|
renamable $eax = DEC32r killed renamable $eax, implicit-def $eflags
|
|
MOV8mi killed renamable $rsi, 1, $noreg, 0, $noreg, 1 :: (store 1)
|
|
...
|