Buffered means a later divide may be executed out-of-order while a
prior divide is sitting (buffered) in a reservation station.
You can tell it's not pipelined, because operations that use it
reserve it for more than one cycle:
def : WriteRes<WriteIDiv, [HWPort0, HWDivider]> {
let Latency = 25;
let ResourceCycles = [1, 10];
}
We don't currently distinguish between an unpipeline operation and one
that is split into multiple micro-ops requiring the same unit. Except
that the later may have NumMicroOps > 1 if they also consume
issue/dispatch resources.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178519
91177308-0d34-0410-b5e6-
96231b3b80d8
def HWPort015 : ProcResGroup<[HWPort0, HWPort1, HWPort5]>;
def HWPort0156: ProcResGroup<[HWPort0, HWPort1, HWPort5, HWPort6]>;
-// Integer division issued on port 0, but uses the non-pipelined divider.
-def HWDivider : ProcResource<1> { let Buffered = 0; }
+// Integer division issued on port 0.
+def HWDivider : ProcResource<1>;
// Loads are 4 cycles, so ReadAfterLd registers needn't be available until 4
// cycles after the memory operand.
def SBPort15 : ProcResGroup<[SBPort1, SBPort5]>;
def SBPort015 : ProcResGroup<[SBPort0, SBPort1, SBPort5]>;
-// Integer division issued on port 0, but uses the non-pipelined divider.
-def SBDivider : ProcResource<1> { let Buffered = 0; }
+// Integer division issued on port 0.
+def SBDivider : ProcResource<1>;
// Loads are 4 cycles, so ReadAfterLd registers needn't be available until 4
// cycles after the memory operand.