The divide unit is not pipeline, but it is still buffered.

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

1 files changed, 2 insertions, 2 deletions

diff --git a/lib/Target/X86/X86SchedSandyBridge.td b/lib/Target/X86/X86SchedSandyBridge.td
index 66d78e4fc4..74d5f1b6eb 100644
--- a/lib/Target/X86/X86SchedSandyBridge.td
+++ b/lib/Target/X86/X86SchedSandyBridge.td
@@ -46,8 +46,8 @@ def SBPort05  : ProcResGroup<[SBPort0, SBPort5]>;
 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.