This is an archive of the discontinued LLVM Phabricator instance.

[DAGCombiner] reassociationCanBreakAddressingModePattern should check uses of the outer add.
ClosedPublic

Authored by craig.topper on Apr 28 2022, 4:24 PM.

Details

Summary

When looking for memory uses,
reassociationCanBreakAddressingModePattern should check uses of
the outer ADD rather than the inner ADD. We want to know if the
two ops we're reassociating are used by a load/store.

In practice, the existing check usually works because CodeGenPrepare
will make one of the load/stores have an offset of 0 relative to
split GEP. That will make the inner add have a memory use.

To test this, I've manually split the GEPs so there is no 0 offset
store.

This issue was recently discussed in the original review D60294.

Diff Detail

Event Timeline

craig.topper created this revision.Apr 28 2022, 4:24 PM
craig.topper requested review of this revision.Apr 28 2022, 4:24 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 28 2022, 4:24 PM
luismarques accepted this revision.May 2 2022, 4:02 PM

LGTM. Thanks for the fix!

This revision is now accepted and ready to land.May 2 2022, 4:02 PM

@craig.topper Have you checked if CombinerHelper::reassociationCanBreakAddressingModePattern (in llvm/lib/CodeGen/GlobalISel/CombinerHelper.cpp) is sound?

@craig.topper Have you checked if CombinerHelper::reassociationCanBreakAddressingModePattern (in llvm/lib/CodeGen/GlobalISel/CombinerHelper.cpp) is sound?

After a quick glance, I think it has the same issue. Was it copied from your original patch?

After a quick glance, I think it has the same issue. Was it copied from your original patch?

I imagine it was inspired by it, to implement the GlobalISel equivalent? I didn't study it closely. Check https://reviews.llvm.org/D105069

This revision was landed with ongoing or failed builds.May 2 2022, 4:43 PM
This revision was automatically updated to reflect the committed changes.