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

Andrea Di Biagio via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 26 03:50:50 PDT 2019


andreadb added a comment.

In D63628#1556559 <https://reviews.llvm.org/D63628#1556559>, @lebedev.ri wrote:

> Thanks for taking a look!
>
> In D63628#1555404 <https://reviews.llvm.org/D63628#1555404>, @andreadb wrote:
>
> > Out of curiosity, did you investigate on why three benchmarks show a 6% slowdown?
>
>
> Actually no, i didn't look at that as of this moment.
>  It doesn't //appear// to be noise, but those 4 tests are essentially covering
>  the same codepath, so the reason will be the same for all of them.


No problem, it was just a curiosity of mine.

> It's certainly not a FPU cluster problem since all those tests are integer (like i said, i didn't do through benchmark...)
>  What's the suggestion there, rebenchmarking with `let PostRAScheduler = 0;` ?

It would be an interesting follow-up investigation to do. However, it shouldn't be a blocker for this patch.



================
Comment at: lib/Target/X86/X86ScheduleBarcelona.td:305
+// to '1' to tell the scheduler that the nop uses an ALU slot for a cycle.
+defm : BnWriteResInt<WriteNop, BnInt012, [BnALU012], 0, [1], 1>; // FIXME
+
----------------
lebedev.ri wrote:
> andreadb wrote:
> > Maybe clarify what there is to FIX.
> > Did you verify that NOPs consume an ALU slot?
> It certainly does as per Agner's instruction_tables.pdf
> There is certainly a hit of a `1` on `retired_uops`.
> There isn't any `IssueCounters` for integer pipelines,
> so there is no direct way to check integer unit consumption i'm afraid :(
> That leaves us with trying to manually measure throughput
> of some high-throughput instruction that can go to any int pipe,
> in the presence of NOP, i suppose (i actually suggested that as way for
> exegesis to indirectly measure unit consumption). I did not do that yet.
Thanks for the info. If Agner says that it consumes 1cy of ALU pipe then it is fine.


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