This re-factoring could cause the following slight changes in generated
code, though none were observed during testing: - MachineScheduler could decide not to cluster some loads/stores if there are other load/stores with non-pairable opcodes that have the same base register and offset as a pairable set of load/stores. One case of different MachineScheduler pairing did show up in my testing, but it wasn't due to this issue, but due BaseMemOpClusterMutation::clusterNeighboringMemOps() being unstable w.r.t. the order it considers memory operations. See PR28942. - The ImplicitNullChecks optimization could be done for more load/store opcodes. This optimization isn't done for C/C++ code, so it didn't show up in my testing.
The getMemOpBaseRegImmOfs() function is used to control lots of moving parts such as the clustering of loads and stores in the MI scheduler, scheduling in the swing modulo scheduler, and implicit null checks in machine sink, for example. Removing this switch and unconditionally calling getMemOpBaseRegImmOfsWidth will return true for many more opcodes (e.g., paired instructions, paired instructions with non-temporal hints, byte and halfword loads/stores).
I just wanted to point this out and confirm that you've done a fair amount of due diligence to make sure this really is a NFC.