[RISCV] Mark vmvNr.v as implicitly using vtype #118414
Conversation
This was pointed out in llvm#118283 (comment). We cannot move these between vtype definitions as they depend on SEW and require vill to be clear.
|
@llvm/pr-subscribers-backend-risc-v Author: Luke Lau (lukel97) ChangesThis was pointed out in #118283 (comment). We cannot move these between vtype definitions as they depend on SEW and require vill to be clear. Full diff: https://github.com/llvm/llvm-project/pull/118414.diff 1 Files Affected:
diff --git a/llvm/lib/Target/RISCV/RISCVInstrInfoV.td b/llvm/lib/Target/RISCV/RISCVInstrInfoV.td
index 8e0c4826ac00de..6506b6746b1517 100644
--- a/llvm/lib/Target/RISCV/RISCVInstrInfoV.td
+++ b/llvm/lib/Target/RISCV/RISCVInstrInfoV.td
@@ -1726,7 +1726,7 @@ foreach n = [1, 2, 4, 8] in {
def VMV#n#R_V : RVInstV<0b100111, !add(n, -1), OPIVI, (outs vrc:$vd),
(ins vrc:$vs2), "vmv" # n # "r.v", "$vd, $vs2">,
VMVRSched<n> {
- let Uses = [];
+ let Uses = [VTYPE];
let vm = 1;
}
}
|
|
I had to update the llvm-mca tests, I'm not sure why adding a use affects the number of cycles. cc @mshockwave |
LGTM as well, the mca change is at least reasonable if we're modeling a new runtime dependency which wasn't previously being modeled. |
Looking at the test. There are vsetvlis interleaved with vmv. So I assume llvm-mca is now waiting for the preceding vsetvli before it can start a vmv. |
Correct, this is the timeline before: And this is the one after: vmvNr no longer can be issued at the same cycle with the preceding vsetvli. |
(Disclaimer: this is just my imagination, real microarchitecture may not be like this) |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/171/builds/11573 Here is the relevant piece of the build log for the reference |
7 participants
This was pointed out in #118283 (comment). We cannot move these between vtype definitions as they depend on SEW and require vill to be clear.