[PATCH] D49310: [llvm-mca][BtVer2] Teach how to identify dependency-breaking idioms.

[Andrea Di Biagio via Phabricator via llvm-commits]

andreadb added a comment.

In https://reviews.llvm.org/D49310#1162667, @lebedev.ri wrote:

> Can you add a comment to the end of the btver sched profile, that `X86MCInstrAnalysis::isDependencyBreaking()`
>  is also responsible (as in, needs to be modified) in detection of dep-breaking patterns?


If the goal is to document this behavior, a comment in the class MCInstrAnalysis should be enough.
If the goal is to provide guidelines for people that want to use llvm-mca, then we should have all this features documented in a .rst file.
In the next future (realistically by the end of august), with the help of Matt, there is a plan improve the llvm-mca documentation. We would describe all the changes that would help improving the analysis in llvm-mca.



================
Comment at: include/llvm/MC/MCInstrAnalysis.h:93
+  ///
+  /// A dependency breaking instruction is know to always compute the same value
+  /// if input register operands are all the same register. An example of
----------------
lebedev.ri wrote:
> s/know/known/?
Thanks. I will fix it.


================
Comment at: lib/Target/X86/MCTargetDesc/X86MCTargetDesc.cpp:317
+                                              const MCInst &Inst) const {
+  if (STI.getCPU() == "btver2") {
+    switch (Inst.getOpcode()) {
----------------
lebedev.ri wrote:
> Hmm. Hardcoding.
> Are there plans on somehow generalizing this, maybe using sched profiles?
There is no plan. I have experimented with alternative approaches.
The 'isDependencyBreaking' could be generated by tablegen for scheduling models. However, it would require a non trivial change in the tablegen backends. In all honestly, I don't think it is worthy to do it just for the sake of better supporting dep-breaking idioms. In my opinion, this patch is simple and less invasive than any other solution involving tablegen.
If we use a tablegen approach, then the only advantage is that we generate nicer checks against CPUID, instead of forcing string compares (CPU names). The rest of the auto-generated code would be pretty much identical (in my experience, a bit less readable). However, we would end up paying a non negligible design cost for a feature that is not critical imho.
So, I don't think that there are better approaches (at least for now).


https://reviews.llvm.org/D49310