[llvm] [TargetInstrInfo] enable foldMemoryOperand for InlineAsm (PR #70743)

[via llvm-commits]

================
@@ -565,6 +565,64 @@ static MachineInstr *foldPatchpoint(MachineFunction &MF, MachineInstr &MI,
   return NewMI;
 }
 
+static void foldInlineAsmMemOperand(MachineInstr *MI, unsigned OpNo, int FI,
+                                    const TargetInstrInfo &TII) {
+  MachineOperand &MO = MI->getOperand(OpNo);
+  const VirtRegInfo &RI = AnalyzeVirtRegInBundle(*MI, MO.getReg());
+
+  // If the machine operand is tied, untie it first.
+  if (MO.isTied()) {
+    unsigned TiedTo = MI->findTiedOperandIdx(OpNo);
+    MI->untieRegOperand(OpNo);
----------------
qcolombet wrote:

> Only registers may be tied.

Yes, what I'm saying is tied operands and untied operands don't have the same semantic and I was wondering if this code could break that.

What I was thinking is, with tied operand, we'll have something like:
```
a = a + ...
```

When we untie and fold, we'll end up with:
```
a = @a + ...
```

At this point, `a` and `@a` don't hold the same value, so we broke the tied operand semantic.
Now, I think this is not a problem for regular code because if `@a` is used somewhere else, regalloc should have produced the correct store operation, i.e.,
```
a = @a + ...
store a, @a <-- values properly tied again
```

My concern is around inline asm that regalloc cannot unbox.
What happens if the inline asm statement is a sequence of instructions:
```
a = a + ...
... = a
```
That we turn into:
```
a = @a
... = @a <-- @a != a
```

https://github.com/llvm/llvm-project/pull/70743