This is an archive of the discontinued LLVM Phabricator instance.

[SystemZ] Fix addcarry of usubo (PR42512)
ClosedPublic

Authored by nikic on Jul 4 2019, 10:27 AM.

Details

Summary

Fixes https://bugs.llvm.org/show_bug.cgi?id=42512.

If I'm understanding things right, the current code assumes that we always see uaddo+addcarry and usubo+subcarry, but no mixtures like usubo+addcarry. If this happens we need to use different flags for the two setcc operations.

Disclaimer: I have no familiarity with SystemZ.

Diff Detail

Repository
rL LLVM

Event Timeline

nikic created this revision.Jul 4 2019, 10:27 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 4 2019, 10:27 AM

Unfortunately, I think this gets the semantics wrong, because "carry" and "borrow" use *different* CC values on SystemZ.

In your example,

slgfi %r0, 1

will set CC 1 if an overflow ("borrow") happened, and CC 2 or 3 if no overflow happened.
But the next instruction,

alcr %r2, %r0

will interpret CC [0 and] 1 as *no* carry to be added, and CC 2 and 3 as carry.

This seems a rather unusual case anyway, can we simply always fall back to the default expansion if the source of the overflow doesn't match the current instruction? I.e. a ISD::ADDCARRY may take its overflow value from a ISD::UADDO or another ISD::ADDCARRY, and a ISD::SUBCARRY may take its overflow value from a ISD::USUBO or another ISD::SUBCARRY, but everything else gets the default expansion?

uweigand requested changes to this revision.Jul 5 2019, 10:04 AM
This revision now requires changes to proceed.Jul 5 2019, 10:04 AM
nikic updated this revision to Diff 208218.Jul 5 2019, 12:03 PM

Fall back to default legalization on add/sub mismatch of the carry generating and consuming operation.

uweigand accepted this revision.Jul 5 2019, 12:53 PM

LGTM, thanks!

This revision is now accepted and ready to land.Jul 5 2019, 12:53 PM
This revision was automatically updated to reflect the committed changes.