[PATCH] D76909: [MachineScheduler] Update available queue on the first mop of a new cycle

[Jinsong Ji via Phabricator via llvm-commits]

jsji added a subscriber: jhibbits.
jsji added a comment.

Looks like this change has more impact to pre-P9 models, especially ppc32/ppc64, which we were using itineraries . (And I know there might be bugs in those itineraries)
Although some changes doesn't look good at first glance, we should dig into itineraries of each model to see whether this is problem in itineraries or due to this change.

@steven.zhang Can you help to look into some of them , especially for P6 <https://reviews.llvm.org/P6>-P8 tests. Thanks.
@jhibbits FYI, you may want to check whether those changes in G3/SPE are good.



================
Comment at: llvm/test/CodeGen/PowerPC/fp128-bitcast-after-operation.ll:31
 ; PPC32-DAG: lwz [[LO0:[0-9]+]], 16(1)
+; PPC32: rlwinm [[FLIP_BIT:[0-9]+]], [[HI0]], 0, 0, 0
 ; PPC32-DAG: lwz [[HI1:[0-9]+]], 28(1)
----------------
This looks like a regression, rlwinm is using HI0, and lwz should be 3-4 cycle.
But we may need to check the itineraries to see whether this is due to resource hazard.


================
Comment at: llvm/test/CodeGen/PowerPC/fp128-bitcast-after-operation.ll:73
 ; PPC32-DAG: xoris [[HI0]], [[HI0]], 32768
+; PPC32-DAG: lwz [[LO1:[0-9]+]], 20(1)
 ; PPC32-DAG: xoris [[LO0]], [[LO0]], 32768
----------------
This looks like unexpected? we are moving something across BARRIER now?


================
Comment at: llvm/test/CodeGen/PowerPC/vec_splat.ll:24
+; G3-NEXT:    fadds 0, 4, 1
 ; G3-NEXT:    stfs 0, 0(3)
 ; G3-NEXT:    blr
----------------
There doesn't look great -- all stfs are waiting fadds now.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76909/new/

https://reviews.llvm.org/D76909