-
Notifications
You must be signed in to change notification settings - Fork 14.3k
[X86] Combine LRINT/LLRINT and TRUNC when TRUNC has nsw flag #126217
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.
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -53919,6 +53919,11 @@ static SDValue combineTruncate(SDNode *N, SelectionDAG &DAG, | |
return DAG.getNode(X86ISD::MMX_MOVD2W, DL, MVT::i32, BCSrc); | ||
} | ||
|
||
if (!Subtarget.useSoftFloat() && N->getFlags().hasNoSignedWrap() && | ||
(Src.getOpcode() == ISD::LRINT || Src.getOpcode() == ISD::LLRINT) && | ||
VT.getScalarType() == MVT::i32 && Src.hasOneUse()) | ||
topperc marked this conversation as resolved.
Show resolved
Hide resolved
|
||
return DAG.getNode(ISD::LRINT, DL, VT, Src.getOperand(0)); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we need to check SSE and not soft float? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. no sse might be ok falling back to x87, but soft float may result in calling lrint/llrint library expecting an i32 result when the result is really i64. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it's ok. It is already UB if the hight 32-bit is not 0 when nuw/nsw is set. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The call lowering code will read from a 32-bit register instead of the real 64-bit register that is written. The upper bits of the 64-bit value could be all 1s if the value is negative. If the i32 result value is used by a zero extend, SelectionDAG will incorrectly remove the zero extend because it thinks the call wrote a 32-bit register which would automatically zero the upper bits. But since the call really wrote 64 bits this would be wrong. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fortunately, SelectionDAG combine There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What if the zext becomes adjacent to the trunc after some other combine or legalization step. There no guarantee the trunc hasn't already been combined with the lrint. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Makes sense, done. |
||
|
||
return SDValue(); | ||
} | ||
|
||
|
Uh oh!
There was an error while loading. Please reload this page.