[midend-SCCP]删除User的析构函数，usedelete增加逻辑通知inst所使用的value移除对应的use关系（一般在这之前会替换使用inst的uses为其他值）,TODO:仍然存在bug需要调试

Pass_ID_List.md

@@ -14,6 +14,62 @@
 
 Mem2Reg 遍的主要目标是将那些不必要的、只用于局部标量变量的内存分配 (alloca 指令) 消除，并将这些变量的值转换为 SSA 形式。这有助于减少内存访问，提高代码效率，并为后续的优化创造更好的条件。
 
+通过Mem2Reg理解删除指令时对use关系的维护：
+
+在 `Mem2Reg` 优化遍中，当 `load` 和 `store` 指令被删除时，其 `use` 关系（即它们作为操作数与其他 `Value` 对象之间的连接）的正确消除是一个关键问题，尤其涉及到 `AllocaInst`。
+
+结合您提供的 `Mem2RegContext::renameVariables` 代码和我们之前讨论的 `usedelete` 逻辑，下面是 `use` 关系如何被正确消除的详细过程：
+
+### 问题回顾：`Use` 关系的双向性
+
+在您的 IR 设计中，`Use` 对象扮演着连接 `User`（使用者，如 `LoadInst`）和 `Value`（被使用者，如 `AllocaInst`）的双向角色：
+
+* 一个 `User` 持有对其操作数 `Value` 的 `Use` 对象（通过 `User::operands` 列表）。
+* 一个 `Value` 持有所有使用它的 `User` 的 `Use` 对象（通过 `Value::uses` 列表）。
+
+原始问题是：当一个 `LoadInst` 或 `StoreInst` 被删除时，如果不对其作为操作数与 `AllocaInst` 之间的 `Use` 关系进行明确清理，`AllocaInst` 的 `uses` 列表中就会留下指向已删除 `LoadInst` / `StoreInst` 的 `Use` 对象，导致内部的 `User*` 指针悬空，在后续访问时引发 `segmentation fault`。
+
+### `Mem2Reg` 中 `load`/`store` 指令的删除行为
+
+在 `Mem2RegContext::renameVariables` 函数中，`load` 和 `store` 指令被处理时，其行为如下：
+
+1.  **处理 `LoadInst`：**
+    当找到一个指向可提升 `AllocaInst` 的 `LoadInst` 时，其用途会被 `replaceAllUsesWith(allocaToValueStackMap[alloca].top())` 替换。这意味着任何原本使用 `LoadInst` 本身计算结果的指令，现在都直接使用 SSA 值栈顶部的 `Value`。
+    **重点：** 这一步处理的是 `LoadInst` 作为**被使用的值 (Value)** 时，其 `uses` 列表的清理。即，将 `LoadInst` 的所有使用者重定向到新的 SSA 值，并把这些 `Use` 对象从 `LoadInst` 的 `uses` 列表中移除。
+
+2.  **处理 `StoreInst`：**
+    当找到一个指向可提升 `AllocaInst` 的 `StoreInst` 时，`StoreInst` 存储的值会被压入值栈。`StoreInst` 本身并不产生可被其他指令直接使用的值（其类型是 `void`），所以它没有 `uses` 列表需要替换。
+    **重点：** `StoreInst` 的主要作用是更新内存状态，在 SSA 形式下，它被移除后需要清理它作为**使用者 (User)** 时的操作数关系。
+
+在这两种情况下，一旦 `load` 或 `store` 指令的 SSA 转换完成，它们都会通过 `instIter = SysYIROptUtils::usedelete(instIter)` 被显式删除。
+
+### `SysYIROptUtils::usedelete` 如何正确消除 `Use` 关系
+
+关键在于对 `SysYIROptUtils::usedelete` 函数的修改，使其在删除指令时，同时处理该指令作为 `User` 和 `Value` 的两种 `Use` 关系：
+
+1.  **清理指令作为 `Value` 时的 `uses` 列表 (由 `replaceAllUsesWith` 完成)：**
+    在 `usedelete` 函数中，`inst->replaceAllUsesWith(UndefinedValue::get(inst->getType()))` 的调用至关重要。这确保了：
+    * 如果被删除的 `Instruction`（例如 `LoadInst`）产生了结果值并被其他指令使用，所有这些使用者都会被重定向到 `UndefinedValue`（或者 `Mem2Reg` 中具体的 SSA 值）。
+    * 这个过程会遍历 `LoadInst` 的 `uses` 列表，并将这些 `Use` 对象从 `LoadInst` 的 `uses` 列表中移除。这意味着 `LoadInst` 自己不再被任何其他指令使用。
+
+2.  **清理指令作为 `User` 时其操作数的 `uses` 列表 (由 `RemoveUserOperandUses` 完成)：**
+    这是您提出的、并已集成到 `usedelete` 中的关键改进点。对于一个被删除的 `Instruction`（它同时也是 `User`），我们需要清理它**自己使用的操作数**所维护的 `use` 关系。
+    * 例如，`LoadInst %op1` 使用了 `%op1`（一个 `AllocaInst`）。当 `LoadInst` 被删除时，`AllocaInst` 的 `uses` 列表中有一个 `Use` 对象指向这个 `LoadInst`。
+    * `RemoveUserOperandUses` 函数会遍历被删除 `User`（即 `LoadInst` 或 `StoreInst`）的 `operands` 列表。
+    * 对于 `operands` 列表中的每个 `std::shared_ptr<Use> use_ptr`，它会获取 `Use` 对象内部指向的 `Value`（例如 `AllocaInst*`），然后调用 `value->removeUse(use_ptr)`。
+    * 这个 `removeUse` 调用会负责将 `use_ptr` 从 `AllocaInst` 的 `uses` 列表中删除。
+
+### 总结
+
+通过在 `SysYIROptUtils::usedelete` 中同时执行这两个步骤：
+
+* `replaceAllUsesWith`：处理被删除指令**作为结果被使用**时的 `use` 关系。
+* `RemoveUserOperandUses`：处理被删除指令**作为使用者（User）时，其操作数**的 `use` 关系。
+
+这就确保了当 `Mem2Reg` 遍历并删除 `load` 和 `store` 指令时，无论是它们作为 `Value` 的使用者，还是它们作为 `User` 的操作数，所有相关的 `Use` 对象都能被正确地从 `Value` 的 `uses` 列表中移除，从而避免了悬空指针和后续的 `segmentation fault`。
+
+最后，当所有指向某个 `AllocaInst` 的 `load` 和 `store` 指令都被移除后，`AllocaInst` 的 `uses` 列表将变得干净（只包含 Phi 指令，如果它们在 SSA 转换中需要保留 Alloca 作为操作数），这时在 `Mem2RegContext::cleanup()` 阶段，`SysYIROptUtils::usedelete(alloca)` 就可以安全地删除 `AllocaInst` 本身了。
+
 ## Reg2Mem
 
 我们的Reg2Mem 遍的主要目标是作为 Mem2Reg 的一种逆操作，但更具体是解决后端无法识别 PhiInst 指令的问题。主要的速录是将函数参数和 PhiInst 指令的结果从 SSA 形式转换回内存形式，通过插入 alloca、load 和 store 指令来实现。其他非 Phi 的指令结果将保持 SSA 形式。