[PATCH] D137440: [RISCV][llvm-mca] Use LMUL Instruments to provide more accurate reports on RISCV

[Michael Maitland via Phabricator via llvm-commits]

michaelmaitland added a comment.

In D137440#3919848 <https://reviews.llvm.org/D137440#3919848>, @reames wrote:

> Longer term, I really do think we need to be able to parse LMUL from vsetvli instructions, and have that influence scheduling of following instructions.  I want to be able to take a program trace, and run it through llvm-mca without having to parse the trace and add annotations before doing so.  Having said that, I have zero objection to the annotation mechanism being proposed here, and think it is useful.  For the actual review, I'll defer to already active reviewers who are a lot more familiar with the internals of MCA that I am.  :)

In the future, I am not opposed to adding support to use the immediate of the vsetvli instruction so annotations are not needed. But there are a few things we must consider:

- I plan on adding the ability to generate assembly that contains the annotations (using llc for example), so you wouldn't need to add annotations yourself on code that you generated anyway. This does not mean reading immediate of vsetvli can't happen. In fact, reading immediates would be helpful if you have assembly you did not generate yourself or didn't generate with the expectation to use it with llvm-mca.
- We would need to be more careful on programs that contained both vsetvli and vsetvl.
- We would need to consider the case where there was an annotation that had one LMUL value but the vsetvli instruction that was associated with the instrument had a different LMUL value. Of course maybe a user messed up writing instrument by hand, but the other alternative is that they originally emitted code that had one LMUL but they wanted to see what the impact is if they used a different LMUL. I think we would be able to control this behavior with a clopt though.

Overall, I think that this suggestion would make using llvm-mca an even better experience on RISCV vector programs, and I'm confident that all the concerns above can be solved.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137440