The merged store touches memory for other underlying objects, so mapping
the merged store to the first underlying object is not correct. For example
in https://github.com/llvm/llvm-project/issues/60744, the merged store is
not correctly analyzed as dependent with memory operations which are also
part of the merged store.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
19168 | I agree that this looks conservatively safe, but I think it will pessimize the case where the MachinePointerInfos had the same underlying pointer. |
llvm/test/CodeGen/X86/merge-store-dependency.ll | ||
---|---|---|
14 | CHECKT -> CHECK |
still reuse the first store pointer info for cases where narrow stores all point to the same underlying object
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
730 | You should not need NumStores. ArrayRef knows its own length. |
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
18995 | This should use getUnderlyingObject() unless there's strong reason to be aggressive here. |
use getUnderlyingObject()
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
18995 | Thanks. Looks good to me. No handling for multiple objects even use getUnderlyingObjects() to reduce the complexity. |
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
18984 | Remove NumStores and use range-based for loops like for (const auto &StoreNode : StoreNodes). Maybe also combine the two loops into one? |
Hi,
I'm seeing a miscompile for my out-of-tree target with this patch. I don't have a reproducer I can share and I'm not sure what is happening yet.
It might very well be something we have broken downstream, but I want to give a heads-up in case other people see problems too.
And now I think it's indeed a downstream bug simply exposed by this patch.
Sorry for the noise!
This should just take one ArrayRef<MemOpLink> argument.