-
Notifications
You must be signed in to change notification settings - Fork 13.5k
[SDAG] Fix/add more legalization cases for FMODF #127976
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 |
---|---|---|
|
@@ -562,7 +562,8 @@ class LLVM_LIBRARY_VISIBILITY DAGTypeLegalizer { | |
// Convert Float Results to Integer. | ||
void SoftenFloatResult(SDNode *N, unsigned ResNo); | ||
SDValue SoftenFloatRes_Unary(SDNode *N, RTLIB::Libcall LC); | ||
SDValue SoftenFloatRes_UnaryWithTwoFPResults(SDNode *N, RTLIB::Libcall LC); | ||
SDValue SoftenFloatRes_UnaryWithTwoFPResults( | ||
SDNode *N, RTLIB::Libcall LC, std::optional<unsigned> CallRetResNo = {}); | ||
SDValue SoftenFloatRes_Binary(SDNode *N, RTLIB::Libcall LC); | ||
SDValue SoftenFloatRes_MERGE_VALUES(SDNode *N, unsigned ResNo); | ||
SDValue SoftenFloatRes_ARITH_FENCE(SDNode *N); | ||
|
@@ -608,6 +609,7 @@ class LLVM_LIBRARY_VISIBILITY DAGTypeLegalizer { | |
SDValue SoftenFloatRes_ExpOp(SDNode *N); | ||
SDValue SoftenFloatRes_FFREXP(SDNode *N); | ||
SDValue SoftenFloatRes_FSINCOS(SDNode *N); | ||
SDValue SoftenFloatRes_FMODF(SDNode *N); | ||
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. Note: |
||
SDValue SoftenFloatRes_FREEZE(SDNode *N); | ||
SDValue SoftenFloatRes_FREM(SDNode *N); | ||
SDValue SoftenFloatRes_FRINT(SDNode *N); | ||
|
Original file line number | Diff line number | Diff line change | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
@@ -2644,8 +2644,10 @@ bool SelectionDAG::expandMultipleResultFPLibCall( | |||||||||||
// optimized out. This prevents an FP stack pop from being emitted for it. | ||||||||||||
// Setting the root like this ensures there will be a use of the | ||||||||||||
// `CopyFromReg` chain, and ensures the FP pop will be emitted. | ||||||||||||
SDValue OldRoot = getRoot(); | ||||||||||||
SDValue NewRoot = | ||||||||||||
getNode(ISD::TokenFactor, DL, MVT::Other, getRoot(), CallChain); | ||||||||||||
OldRoot ? getNode(ISD::TokenFactor, DL, MVT::Other, OldRoot, CallChain) | ||||||||||||
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. Why is this null here? 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. Ugh, it's because of: llvm-project/llvm/lib/CodeGen/SelectionDAG/LegalizeTypes.cpp Lines 209 to 211 in dc326d0
Which then later ignores any changes to the root: llvm-project/llvm/lib/CodeGen/SelectionDAG/LegalizeTypes.cpp Lines 438 to 439 in dc326d0
Which I think would be incorrect for the workround the multiple-result expansions are doing. 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've reverted the clang PR while I look into this further) 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 this will have to be updated to preserve the root created during legalize types, as otherwise the workaround needed for functions like 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. Well, whether or not it's okay to ignore the new root created by the expansion workround depends on if the ignored result is returned via some sort of stack, that needs to be popped regardless of if that value is used or not. That depends on the target, as far as I know it's only really x86 where that is an issue? |
||||||||||||
: CallChain; | ||||||||||||
setRoot(NewRoot); | ||||||||||||
// Ensure the new root is reachable from the results. | ||||||||||||
Results[0] = getMergeValues({Results[0], NewRoot}, DL); | ||||||||||||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any thoughts? I can't think of an obvious way to avoid the need of the workaround for the expansion of
modf
andfrexp
, and I don't think it's safe to do if LegalizeTypes types just blindly ignores any changes to the root.