This change sink a spill into a successor, if reloads from the stack slot
are reachable only through the successor.
For the machine IR below, we will sink the store to %stack.0 in bb.0 into
bb.1 because there is no reload from stack.0 in bb.2.
bb.0: STRXui $x0, %stack.0, 0 Bcc 11, %bb.2 bb.1: $x0 = LDRXui %stack.0, 0 RET $x0 bb.2: $x0 = COPY $xzr RET $x0
From what I see, hasLoadFromStackSlot checks for MachineMemoryOperands attached to the MI. It looks for things like :: (load 8 from %stack.0), and if the load source is a fixed stack it grabs the FI.
I wonder what happens if an instruction:
I've been confused about MachineMemoryOperands for a while now, so I'm not sure if an instruction with no MMOs should act like a barrier or something else. Are there any other passes that rely on this?
What do you think? I think if we can rely on MMOs it would be great, and we should document it somewhere.
This shouldn't be blocking for this patch, but if you can document these assumptions it would be great.