Skip to content
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

[SCCP] [Transform] Adding ICMP folding for zext and sext in SCCPSolver #67594

Closed
wants to merge 2 commits into from

Conversation

leo-ard
Copy link
Contributor

@leo-ard leo-ard commented Sep 27, 2023

This PR fixes #55013 : the max intrinsics is not generated for this simple loop case : https://godbolt.org/z/hxz1xhMPh. This is caused by a ICMP not being folded into a select, thus not generating the max intrinsics.

Since LLVM 14, SCCP pass got smarter by folding sext into zext for positive ranges : https://reviews.llvm.org/D81756. After this change, InstCombine was sometimes unable to fold icmp correctly as both of the arguments pointed to mismatched zext/sext. To fix this, @rotateright implemented this fix : https://reviews.llvm.org/D124419 that tries to resolve the mismatch by knowing if the argument of a zext is positive (in which case, it is like a sext) by using ValueTracking. However, ValueTracking seems to be not smart enough for this case and cannot accurately know that the value is positive or not. This PR implements the folding in SCCP directly, where we have the knowledge that the value are positive or not.

This PR also contains test cases for sext/zext folding with SCCP as well as a x86 regression tests for the max/min case.

@llvmbot llvmbot added clang Clang issues not falling into any other category backend:X86 function-specialization llvm:transforms labels Sep 27, 2023
@github-actions
Copy link

github-actions bot commented Sep 27, 2023

✅ With the latest revision this PR passed the C/C++ code formatter.

Copy link
Contributor

@mariannems mariannems left a comment

Choose a reason for hiding this comment

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

Thanks for fixing that regression!

}


if(Op0->getType() != Op1->getType()){
Copy link
Contributor

Choose a reason for hiding this comment

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

Its is always better to exit early. This check should ideally be done before potential swapping.

@@ -0,0 +1,185 @@
; NOTE: Assertions have been autogenerated by utils/update_test_checks.py UTC_ARGS: --tool ./bin/opt --version 3
; See PRXXX for more details
Copy link
Contributor

Choose a reason for hiding this comment

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

See PRXXX Was that autogenerated ? Does it need to be updated ?

if (Op1_zext && (!Op0_zext)) {
// We force Op0 to be a zext and reverse the arguments
// at the end if we swap
reversed = true;
Copy link
Contributor

Choose a reason for hiding this comment

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

IMHO the swapping makes it harder to read. Not swapping would force case to be checked in the if statement, but would make the code more readable.

Copy link
Contributor

@nikic nikic left a comment

Choose a reason for hiding this comment

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

If I understood correctly, what you're trying to do here is to apply an icmp fold early before the sext -> zext information gets lost. I don't think this is the correct way to approach the problem. The correct way is to preserve the fact that the operand is non-negative when converting to zext, which would allow the InstCombine fold to reliably undo this. In fact, there is a pending patch for this at https://reviews.llvm.org/D156444.

@nikic nikic requested a review from fhahn September 27, 2023 20:21
@leo-ard
Copy link
Contributor Author

leo-ard commented Sep 27, 2023

If I understood correctly, what you're trying to do here is to apply an icmp fold early before the sext -> zext information gets lost. I don't think this is the correct way to approach the problem. The correct way is to preserve the fact that the operand is non-negative when converting to zext, which would allow the InstCombine fold to reliably undo this. In fact, there is a pending patch for this at https://reviews.llvm.org/D156444.

When tackling this problem, my first idea was to track the non-negativeness of the zext and use this information in InstCombine. I didn't know that you could do it through flags in the IR, which I think is a cleaner solution. Do you think this patch will be available soon ?

@leo-ard leo-ard mentioned this pull request Oct 2, 2023
@leo-ard
Copy link
Contributor Author

leo-ard commented Oct 31, 2023

I'm closing this PR in favour of #70845

@leo-ard leo-ard closed this Oct 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend:X86 clang Clang issues not falling into any other category function-specialization llvm:transforms
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Instruction pmaxsw not generated
4 participants