This is an archive of the discontinued LLVM Phabricator instance.

[NewGVN] Improve phi-of-ops fix to allow loads that loop invariant-ish
AbandonedPublic

Authored by nlopes on Jan 30 2022, 11:11 AM.

Details

Reviewers
asbirlea
fhahn
Summary

My previous fix for the phi-of-ops was a bit of a big hammer.
This patch uses Memory SSA to detect when a load is guaranteed to not depend on a store that may happen inside the loop.

This patch fixes the regression in storeoverstore.ll, where the big hammer had disabled phi-of-ops for this test case.

Diff Detail

Unit TestsFailed

Event Timeline

nlopes created this revision.Jan 30 2022, 11:11 AM
nlopes requested review of this revision.Jan 30 2022, 11:11 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 30 2022, 11:11 AM

Thank you for looking at this! Please see inline.

llvm/lib/Transforms/Scalar/NewGVN.cpp
2601
if (!OriginalAccess)
  return true;

(if instruction is not modeled in MSSA)

2612

A clobbering access (DefiningAccess) always dominates the queried access (OriginalAccess), so the second condition is redundant.
Now, is the first condition (different BBs) enough? I don't think it is. The store can still be inside the loop but in an earlier block.

BBa (store)  -> BBb -> BBd (load) -
    ^        \-> BBc /^          |
    |____________________________|

Inserting the phi-of-ops in BBa is incorrect, if the load will use the value from phi-of-ops instead of reloading. This example is what I was seeing in one of the bug reports (one load was in BBa and it's covered by the tests here, another was in BBd.

I think the condition here is something like if (DT->properlyDominates(DefiningAccess->getBlock(), PHIBlock)).

Herald added a project: Restricted Project. · View Herald TranscriptJul 23 2023, 7:47 AM