The attached patch is a first step to (hopefully) using less monolithic "ADDRESS!!!" operands for load/store operations on ARM64 while still allowing C++ selection (to avoid AArch64's TableGen pattern nightmare).
The idea is that instead of just being able to use ComplexPatterns as leaf nodes (e.g. "my_pat:$address") you can specify how the results map to named operands on a finer level: "(my_pat GPR64:$base, imm:$offset)".
I believe the only XYZGenDAGISel.inc changed by this patch is the Hexagon one, and looking at the file its changes appear sensible.
The Hexagon change is actually a bugfix that this code revealed, but serves as a reasonable example for the code: what *was* happening was that the Hexagon result instructions were getting the ComplexPattern *input* and a newly-materialized "0" as an operand: the ComplexPattern results were being ignored completely. Since the ComplexPatterns were so trivial this didn't actually affect any output, but it was fairly clearly not intended.
So how does it look?