-
Notifications
You must be signed in to change notification settings - Fork 15.4k
[LV] Support argmin/argmax with strict predicates. #170223
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
Open
fhahn
wants to merge
1
commit into
llvm:main
Choose a base branch
from
fhahn:lv-argmin-argmax-find-first
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+1,115
−247
Open
Changes from all commits
Commits
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 hidden or 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 hidden or 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 hidden or 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 hidden or 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 hidden or 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 hidden or 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.
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.
The sentinel value should be outside AR's range, when FindFirstIV or FindLastIV work with a condition that may be false for all values inside AR's range, as in that case the out-of-bound sentinel value helps to convey that answer. But for argmin/argmax with strict/FirstIV or non-strict/LastIV, the condition is guaranteed to be true at-least once inside AR's range. So having a sentinel inside AR's range should be fine?
Follow-up thought: even if the condition may be false for all values inside AR's range, but the final value to return in that case coincides with the natural sentinel inside AR's range, it could potentially also be optimized as above. E.g., suppose FindLastIV work with an arbitrary condition a[i]>0 in the range [0,100], where if all a's are zeroes the value to return is 0.
Another thought: argmin/argmax is interesting not only because it's condition is guaranteed to hold at-least once in the range, but also because it supports FindFirstIV naturally (w/o negating the IV - which conceptually still means it's a FindLastIV but on a decreasing derived IV) - by relying on the running min/max recurrence whose strict comparison precludes repeated occurrences. This relates to a discussion we had on some earlier patch, where adding another, dependent (boolean "found") recurrence was found to have significant negative impact.
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 am not sure if currently the condition must hold at least once unless I am missing something, because there are no restrictions on the start values e.g. the minimum reduction does not have to start at the max value, so the IV may never get selected in the loop, and the minimuxm index reduction may start at a value that's different to the IV start value.
But IV start == min.idx start and condition known to be true at least once are good to optimize separately. Note that for the initial FindLastIV, the range is checked during the IVDescriptor analysis.