[PATCH] D94928: [llvm-mca] Add support for in-order CPUs

Andrea Di Biagio via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Feb 17 06:12:34 PST 2021


andreadb added a comment.

Now that https://reviews.llvm.org/D95954 has been fixed, there are only a few things left to do:

1. Disable the bottleneck analysis for in-order processors.
2. Add a couple of lines to the release notes describing this new feature.
3. Update the llvm-mca docs.

About the bottleneck analysis view:
Current implementation works under the assumption that the processor is out-of-order. It internally observes events generated by the scheduler, as well as instruction state transitions. It correlates those events with scheduler queue availablity to track pressure increases due to data dependencies etc. For in-order processors, we need a completely different logic; the existing logic would not work (as you can tell from one of the tests that you have added where no bottleneck is reported for data dependencies!).

We should raise a warning from the llvm-mca driver if the user explicitly requested the bottleneck analysis, and the processor is in-order. The warning should mention that the bottleneck analysis is currently unsupported for in-order processors. Note also that flag -all-views should automatically enable the bottleneck analysis if the processor is in-order.

About the documentation: in a few paragraphs we mention "out-of-order" backends. In most cases, it is just a matter of removing the word "out-of-order", and the rest of the paragraph is still valid.
However, section "Instruction Flow" requires an extra paragraph for in-order processors. The instruction flow is much simpler for in-order processors, and the dispatch event is not decoupled from the issue event. Also, the instruction issue is handled by a new stage named "InOrderIssue".
Please add a new section for your new "InOrderIssue" stage (ideally, it should go after the "Write-Back and Retire Stage" section). There you should briefly mention what happens to instructions during that stage. Please also add a small paragraph explaining how the current model allows for out-of-order execution of writes that are specially marked in the scheduling model.

I think this is all.
I plan to accept the patch once those three points are addressed.

Thanks,
-Andrea


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94928



More information about the llvm-commits mailing list