This is an archive of the discontinued LLVM Phabricator instance.

[PHITranslateAddr] Require dominance when searching for translated address (PR57025)
ClosedPublic

Authored by nikic on Aug 30 2022, 5:36 AM.

Details

Summary

This is a fix for PR57025 and an alternative to D131776. The problem in the memdep-unknown-deadblocks.ll test case is that phi translation of gep %arr, %j into store.done looks for a GEP of the form gep %arr, %i and picks the one in the store.idx.i block. While this instruction has the correct pointer address, it occurs in a context where %i != 0. As such, we get a NoAlias result for the store in store.idx.0 block, even though they do alias for %i == 0 (which is legal in the original context of the pointer).

PHITranslateValue already has a MustDominate option, which can be used to restrict PHI translation results to values that dominate the translated-into block. However, this is more aggressive than what we need and would significantly regress GVN results. In particular, if we have a pointer value that does not require any translation, then it is fine to continue using that value in the predecessor, because the context is still correct for the original query. We only run into problems if PHITranslateSubExpr() picks a completely random instruction in a context that may have preconditions that do not hold.

Fix this by always performing the dominance checks in PHITranslateSubExpr(), without enabling the more general MustDominate requirement.

Fixes https://github.com/llvm/llvm-project/issues/57025. This also fixes the test case for https://github.com/llvm/llvm-project/issues/30999, but I'm not sure whether that's just the particular test case, or a general solution to the problem.

Depends on D131775.

Diff Detail

Event Timeline

nikic created this revision.Aug 30 2022, 5:36 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 30 2022, 5:36 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
nikic requested review of this revision.Aug 30 2022, 5:36 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 30 2022, 5:36 AM

Thank you for digging to figure this out. I believe this is the right solution here, but please wait for other's input too.

nikic updated this revision to Diff 456873.Aug 31 2022, 12:18 AM

Rebase over another test llvm/test/Transforms/GVN/phi-translation-to-wrong-context.ll, which I think makes the root cause of the issue easier to understand, and doesn't involve unreachable code or loops.

asbirlea accepted this revision.Aug 31 2022, 2:14 PM

Wow on that last test O_o.

This revision is now accepted and ready to land.Aug 31 2022, 2:14 PM
fhahn added a comment.Sep 1 2022, 8:02 AM

Thanks for the fix, LGTM as well.

, if we have a pointer value that does not require any translation, then it is fine to continue using that value in the predecessor, because the context is still correct for the original query.

Could we just check for that case in translation and then always set MustDominate to true?

nikic added a comment.Sep 1 2022, 8:04 AM

Thanks for the fix, LGTM as well.

, if we have a pointer value that does not require any translation, then it is fine to continue using that value in the predecessor, because the context is still correct for the original query.

Could we just check for that case in translation and then always set MustDominate to true?

I don't think so, in that we do need the current strict MustDominate behavior when we check whether the translated value needs to be materialized in the predecessor during PRE.