[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