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

lib/Target/X86/X86SchedHaswell.td

@@ -50,8 +50,8 @@ def HWPort15  : ProcResGroup<[HWPort1, HWPort5]>;
 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.

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.