-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
[InstCombine] canonicalize sign bit checks #122962
Closed
Closed
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
1e39a63
[InstCombine][NFC] precommit tests for signed floor division
jacobly0 a31cf76
[InstCombine] fold unsigned predicates to signed on srem result
jacobly0 89fdfb6
[InstCombine][NFC] precommit tests for sign bit check canonicalization
jacobly0 32ab6ee
[InstCombine] canonicalize sign bit checks
jacobly0 File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
At least IMO, more useful than just building to just maximally constrain the
icmp
. I.e if you haveicmp ugt X, 10
and can actually narrow it toicmp ugt X, 129
, thats better thanicmp slt X, 0
.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.
I'm trying to use a form that other combines will recognize as a sign check, such as
icmp slt X, 0
oricmp ugt X, smax
. I'm also not clear which side is considered maximally constrained here. For example if-5 <= X <= 5
thenicmp ugt X, -6
<=>icmp ugt X, smax
<=>icmp slt X, 0
<=>icmp ugt X, 5
. I'm choosing the signed comparison, which is exactly equivalent to comparing to smax, because sign checks can be cheaper and have special combines written for them.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.
I do think it would be possible to update the downstream combines to handle a different canonical form. My main worry is losing out in the backend on various shifting tricks and simpler sign checks that don't require loading a potentially large constant and which are localized to only needing to check one bit for large integers. I'm sure this could be mitigated by moving the range checks and sign bit check preference into the backends that care, but it certainly does not appear to currently be the case.
Under the assumption that the issue is that more information could be gained by moving the comparison constant to one of the extremes, I'm still unclear on how to choose one side of the range as more beneficial. It seems like some information is lost on each side, by reducing the known range on either a true or false branch, which is only gained back by recomputing ranges. At that point, the choice of constant does not seem to affect the information you have, because the source range is always split into the same two ranges by any choice of constant.
If you want to limit it to only changing the constant of an existing icmp and not changing the signedness of the predicate, then that seems perfectly reasonable and potentially simple to implement. If you have a specific definition of canonical other than preferring strict sign bit checks, I could also try to see if I could make it work.
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.
I think is depends heavily on the use. I can see the case where if you are branching on the
cmp
then maximally constraining it in one direction leaves us with the least useful region on the other side. But in other use-cases whether only thetrue
(orfalse
) value matters we would almost certaintly want maximal constraint. I.e(select (icmp ult X, 4), f(X), C)
is almost always better(select (icmp sge X, 0), f(X), C)
.I guess I can see sign-compare is a general middle-ground. Although I think this fold is liable to cause regressions in cases that it relaxes the constraints on a
cmp
that dominates some important expressions.Truthfully not sure what the correct approach here is. I guess in some ideal case I would think some cost-function to decide which direction of the
cmp
is liable to benefit most from being maximally constrained, altough that might be overkill, especially in InstCombine.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.
Yep, that totally makes sense now, and I don't really have a better solution to propose at the moment.
Do you have a suggestion for how to proceed with my original
add (sdiv X, C), sext i1 (icmp ugt (srem X, C), smin)
=>ashr X, log2(C)
use case in the short term, and in a way that won't need to be reverted? Is my original PR that only applies tosrem
seem restricted enough enough to avoid major regressions (especially given the relative rareness ofsrem
), or should I revert back to something like my initial code which only applied where the full originalfoldICmpSRemConstant
is applicable, just slightly improved based on what I have learned from these generalizations?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.
Are you talking about #122520? If so I think that can in without further changes.