This is an archive of the discontinued LLVM Phabricator instance.

[NewGVN] do phi(undef, x) -> x only if x is not poison
ClosedPublic

Authored by nlopes on Jan 21 2022, 9:36 AM.

Details

Summary

phi([undef, A], [x, B]) -> x is only correct x is guaranteed to be a non-poison value. Otherwise we would be changing an undef to poison in the branch A.

This patch fixes this bug in NewGVN.

Diff Detail

Event Timeline

nlopes created this revision.Jan 21 2022, 9:36 AM
nlopes requested review of this revision.Jan 21 2022, 9:36 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 21 2022, 9:36 AM
asbirlea accepted this revision.Jan 25 2022, 4:30 PM

Thank you!

This revision is now accepted and ready to land.Jan 25 2022, 4:30 PM
nikic requested changes to this revision.Jan 26 2022, 12:15 AM
nikic added a subscriber: nikic.

It looks like the current behavior matches what GVN does: https://llvm.godbolt.org/z/eTYzMjKf7

If an issue affects both GVN and NewGVN, please always fix it in GVN first. Otherwise the fix will remain untested, and this seems like a situation where it can cause a real regression in optimization quality (because we still treat uninit loads as undef, not poison).

This revision now requires changes to proceed.Jan 26 2022, 12:15 AM

It looks like the current behavior matches what GVN does: https://llvm.godbolt.org/z/eTYzMjKf7

If an issue affects both GVN and NewGVN, please always fix it in GVN first. Otherwise the fix will remain untested, and this seems like a situation where it can cause a real regression in optimization quality (because we still treat uninit loads as undef, not poison).

The bug is not in GVN itself, it's in InstSimplify (which is called by GVNPass::processInstruction).
I do have a patch for InstSimplify as well, but given the potential to regress performance, I would rather delay that until after the LLVM 14 branch.

It looks like the current behavior matches what GVN does: https://llvm.godbolt.org/z/eTYzMjKf7

If an issue affects both GVN and NewGVN, please always fix it in GVN first. Otherwise the fix will remain untested, and this seems like a situation where it can cause a real regression in optimization quality (because we still treat uninit loads as undef, not poison).

The bug is not in GVN itself, it's in InstSimplify (which is called by GVNPass::processInstruction).
I do have a patch for InstSimplify as well, but given the potential to regress performance, I would rather delay that until after the LLVM 14 branch.

@nikic do you agree with this plan (commit this patch now and fix InstSimplify after 14 branches in a few weeks)?

This revision was not accepted when it landed; it landed in state Needs Revision.Jan 29 2022, 1:44 PM
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.