[llvm] [RISCV] Add guard to prevent GPRPair merge on targets without Zdinx or P (PR #186600)
Kavin Gnanapandithan via llvm-commits
llvm-commits at lists.llvm.org
Sun Mar 15 14:05:16 PDT 2026
KavinTheG wrote:
> I think we probably need to know from the first candidate for merging, what it can be merged with, before preceeding. Right now this is sort-of enforced with a bunch of bools and invoking very similar copies of functions, maybe that's where the confusion is coming from?
Perhaps using enums like a `MergeCandidateKind` can make this less confusing? It could be used to indicate clearly what type the candidate is and use a switch to call the appropriate find & merge function?
I took a very brief look at `AArch64LoadStoreOptimizer.cpp` which has a very similar function that merges two instructions into a single pair-wise instruction `mergePairedInsns` and it uses a struct `LdStPairFlags` as a function parameter to keep track of bool flags. I think something akin to the former would be more of an incremental update though, but perhaps this could be ameliorated in another patch?
> maybe we're not merging cm.mv* pairs where the a1 move comes before the a0 move
Apologies if I'm misunderstanding your statement but I believe we do merge `cm.mv*` pairs where the `a1` comes before `a0` according to the comments in `mergePairedInsns`? It swaps the order based on which instruction holds `a0`.
```
// The order of S-reg depends on which instruction holds A0, instead of
// the order of register pair.
// e,g.
// mv a1, s1
// mv a0, s2 => cm.mva01s s2,s1
//
// mv a0, s2
// mv a1, s1 => cm.mva01s s2,s1
```
https://github.com/llvm/llvm-project/pull/186600
More information about the llvm-commits
mailing list