When rematerialize a virtual register the register may be early clobbered. However rematerializeAt(...) just return the slot index of Slot_Register which cause mis-calculating live range for the register --------- Co-authored-by: Yuanke Luo <ykluo@birentech.com>
Only one caller cares about the true case of this parameter, so move the check to that single caller. Note that RegisterCoalescer seems like it should care, but it already duplicates the check several lines above.
Fixes the "use after poison" issue introduced by #121516 (see <https://github.com/llvm/llvm-project/pull/121516#issuecomment-2585912395>). The root cause of this issue is that #121516 introduced "Called Global" information for call instructions modeling how "Call Site" info is stored in the machine function, HOWEVER it didn't copy the copy/move/erase operations for call site information. The fix is to rename and update the existing copy/move/erase functions so they also take care of Called Global info.
When LiveRangeEdit::eliminateDeadDef() converts an MI to a KILL instruction, it should also call dropMemRefs() in order to erase any MachineMemOperand present. This was discovered in testing as the MachineVerifier does not accept an MMO without the corresponding MI mayLoad/mayStore flag, which the KILL opcode lacks.
This `AA` parameter is not used and for most uses they just pass a nullptr. The use of `AA` was removed since 8d0383e.
I noticed this was possibly buggy with implicit operands with the same dest register, and should maybe be using addRegisterDead. However, this is never called in a situation where the operand wasn't already marked dead. This is eliminateDeadDef, implying the def was already known to be dead. Add an assert to detect inconsistencies in dead flags. This was apparently added in 9a16d655c71826bef98b7d6e9590e4494ac0e1a9.
It's allowed to rematerialize instructions with implicit-defs of the same register as the single explicit def. If this happened, it was only clearing the dead flags on the one main result.
This reverts commit a496c8be6e638ae58bb45f13113dbe3a4b7b23fd. The workaround in c26dfc81e254c78dc23579cf3d1336f77249e1f6 should work around the underlying problem with SUBREG_TO_REG.
And dependent commits. Details in D150388. This reverts commit 825b7f0ca5f2211ec3c93139f98d1e24048c225c. This reverts commit 7a98f084c4d121244ef7286bc6503b6a181d446e. This reverts commit b4a62b1fa546312d882fa12dfdcd015177d66826. This reverts commit b7836d856206ec39509d42529f958c920368166b. No conflicts in the code, few tests had conflicts in autogenerated CHECKs: llvm/test/CodeGen/Thumb2/mve-float32regloops.ll llvm/test/CodeGen/AMDGPU/fix-frame-reg-in-custom-csr-spills.ll Reviewed By: alexfh Differential Revision: https://reviews.llvm.org/D156381