[llvm] [MCP] Bug fix for reverted patch #70778 (PR #74239)

[via llvm-commits]

LWenH wrote:

In issue https://github.com/llvm/llvm-project/issues/73512, considering the following instruction sequence during the **ForwardCopyPropagateBlock** procudure:

```
L1 : $sgpr2_sgpr3 = COPY $sgpr6_sgpr7
L2 : $sgpr0 = COPY $sgpr3
L3 : S_NOP 0, implicit-def $sgpr0
L4 : $sgpr3 = COPY killed $sgpr5
L5 : $sgpr2_sgpr3 = COPY $sgpr6_sgpr7
L6 : S_NOP 0, implicit $sgpr2_sgpr3
```

I tried to debug the routine of **ForwardCopyPropagateBlock**, consider we have the following register unit for amdgpu register(just assum):
```
sgpr2: 0, 1
sgpr3: 2, 3
sgpr6: 4, 5
sgpr7: 6, 7
sgpr0: 8, 9
```
When we after processing L2, we have the following records in the copy maps:
![image](https://github.com/llvm/llvm-project/assets/39164871/cea886d6-f1bb-4a63-aaf5-91af5fff29d9)

But when we processing L3, we need to implicit clobber the register sgpr0, we directly remove the record since it's
DefRegs is being empty:

![image](https://github.com/llvm/llvm-project/assets/39164871/677368af-221e-402f-bac3-a51b2be6ddd7)

Then when we reach L4, we need to mark L1 as unavailable during the propagation procedure.
Howerver，we will no longer to find the L1 in Copy Maps since the record of sgpr3 is being deleted.

In this patch, we should make sure that the although SrcCopy's DefRegs maybe empty after "cleaning up" ,
it should not be directly remove from copy maps if it's MI is not NULL.


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