[llvm] [SelectionDAG][RISCV] Avoid store merging across function calls (PR #130430)
Philip Reames via llvm-commits
llvm-commits at lists.llvm.org
Wed Mar 19 10:57:16 PDT 2025
================
@@ -21152,6 +21158,48 @@ bool DAGCombiner::checkMergeStoreCandidatesForDependencies(
return true;
}
+bool DAGCombiner::hasCallInLdStChain(SmallVectorImpl<MemOpLink> &StoreNodes,
+ SmallVectorImpl<MemOpLink> &LoadNodes,
+ unsigned NumStores) {
+ for (unsigned i = 0; i < NumStores; ++i) {
+ StoreSDNode *St = cast<StoreSDNode>(StoreNodes[i].MemNode);
+ LoadSDNode *Ld = cast<LoadSDNode>(LoadNodes[i].MemNode);
+ assert(Ld == cast<LoadSDNode>(peekThroughBitcasts(St->getValue())) &&
+ "Load and store mismatch");
+
+ SmallPtrSet<const SDNode *, 32> Visited;
+ SmallVector<std::pair<const SDNode *, bool>, 8> Worklist;
+ Worklist.emplace_back(St->getChain().getNode(), false);
+
+ while (!Worklist.empty()) {
+ auto [Node, FoundCall] = Worklist.pop_back_val();
+ if (!Visited.insert(Node).second || Node->getNumOperands() == 0)
+ continue;
+
+ switch (Node->getOpcode()) {
+ case ISD::CALLSEQ_END:
+ Worklist.emplace_back(Node->getOperand(0).getNode(), true);
+ break;
+ case ISD::TokenFactor:
+ for (SDValue Op : Node->ops())
+ Worklist.emplace_back(Op.getNode(), FoundCall);
+ break;
+ case ISD::LOAD:
+ if (Node == Ld)
+ return FoundCall;
+ [[fallthrough]];
+ default:
+ assert(Node->getOperand(0).getValueType() == MVT::Other &&
+ "Invalid chain type");
+ Worklist.emplace_back(Node->getOperand(0).getNode(), FoundCall);
+ break;
+ }
+ }
+ return false;
----------------
preames wrote:
Hm, thinking about it, not sure we need to check any of the others. (As in, we don't need the loop, and can only check the first pair.) My reasoning is that for a call to be before LD2 and ST2, but not LD1 and ST2, then the call has to be between either LD1 and LD2 or ST1 and ST2. In either case, either the call aliases the memory operation (preventing the merging entirely), or we can insert the merged LD or ST on whichever side of the call we prefer avoiding the issue.
I haven't glanced at the code to see if it actually takes advantage of that rescheduling. A couple of additional test cases coming...
https://github.com/llvm/llvm-project/pull/130430
More information about the llvm-commits
mailing list