[PATCH] D63628: AMD K10 (Barcelona) Initial Scheduler model

Roman Lebedev via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Jun 29 15:03:51 PDT 2019


lebedev.ri marked 3 inline comments as done and an inline comment as not done.
lebedev.ri added inline comments.


================
Comment at: lib/Target/X86/X86ScheduleBarcelona.td:24
+  let MicroOpBufferSize = 72; // 24 lines of three macro-ops.
+  let LoopMicroOpBufferSize = -1; // There does not seem to be a loop buffer.
+  let LoadLatency = 3; // The L1 data cache has a 3-cycle load-to-use latency.
----------------
andreadb wrote:
> You can safely remove this line.
> The default value of LoopMicroOpBufferSize is already -1.
Isn't it better to be specific, since we know the answer (`no loop buffer`), instead of relying on whatever default there is currently?


================
Comment at: lib/Target/X86/X86ScheduleBarcelona.td:45-48
+def BnRCU : RetireControlUnit<72, 3>;
+// FIXME: it isn't that simple actually.
+// It's not 72 entries, but more like 24 "entries", each entry tracking
+// up to 3 lanes.
----------------
andreadb wrote:
> I think that your definition of RetireControlUnit is fine.
> The RCU is definitely 72 entries. It internally tracks macro-ops contributed to each pipeline. The fact that instructions are distributed among three different pipes after Fetch shouldn't really affect the description of the RCU in LLVM (or require future any changes in future). In practice, you can assume a uniform distribution of decoded ops on the three pipelines. Basically, I don't think that you need a FIXME here.
> 
Okay, thank you for a second opinion. I do think it's okay-ish for it's current purposes.
I'll change it to `NOTE`, since i'd think it would be good to still record such info.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D63628





More information about the llvm-commits mailing list