Skip to content

[SelectionDAG] Calculate KnownBits for SMIN #85584

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

[SelectionDAG] Calculate KnownBits for SMIN #85584

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 10 additions & 2 deletions llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4007,8 +4007,6 @@ KnownBits SelectionDAG::computeKnownBits(SDValue Op, const APInt &DemandedElts,

// For SMAX, if CstLow is non-negative we know the result will be
// non-negative and thus all sign bits are 0.
// TODO: There's an equivalent of this for smin with negative constant for
// known ones.
if (IsMax && CstLow) {
const APInt &ValueLow = CstLow->getAPIntValue();
if (ValueLow.isNonNegative()) {
Expand All @@ -4017,6 +4015,16 @@ KnownBits SelectionDAG::computeKnownBits(SDValue Op, const APInt &DemandedElts,
}
}

// For SMIN, if CstHigh is negative we know the result will be
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand why any of this SMIN/SMAX handling code is needed, except for the call to KnownBits::smin/smax. Those functions are optimal, and the code here does not seem to use any knowledge that is not captured by KnownBits info.

Copy link
Collaborator

@topperc topperc Mar 19, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's possible to know the LHS has some number of sign bits without knowing whether it is positive or negative. Here's the patch that added the SMAX code https://reviews.llvm.org/D126896

The issue was that we knew the sign bit of the smax was zero before type legalization when the type was i32. This turned a sext into a sext. Then we promoted to i64 and known bits would only say bit 63 of the i64 smax was known zero. That patch made compute known bits say at least 63:31 were known zero to match what we knew before type legalization.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks - I see now that using numsignbits info does let it deduce more stuff than KnownBits can.

// negative and thus all sign bits are 1.
if (!IsMax && CstHigh) {
const APInt &ValueHigh = CstHigh->getAPIntValue();
if (ValueHigh.isNegative()) {
unsigned SignBits = ComputeNumSignBits(Op.getOperand(0), Depth + 1);
Known.One.setHighBits(std::min(SignBits, ValueHigh.getNumSignBits()));
}
}

break;
}
case ISD::UINT_TO_FP: {
Expand Down