-
Notifications
You must be signed in to change notification settings - Fork 14.9k
[mlir][vector] Improve vector.gather description #153278
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
Merged
Merged
Changes from all commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
7b9cff1
tighten the example
newling 6b431e3
add IR snippet for 3-D to 2-D, remove comment about gradual lowering
newling 52133ed
k-1 clarify
newling 8e9936b
indentation fix
newling e8b8de3
Merge branch 'main' into vector_gather_doc_improvement
newling 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
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.
This could also be written as:
As in,
base[i0, i1, i2]
provides the base address and thenindex_vec[i,j]
is the "element" index, similarly to how pointer arithmetic works in C.I wanted to bring it up to make sure that our interpretations are consistent. If that's the case, then I would consider rephrasing:
(which assumes one interpretation) as
This is a bit tricky/nuanced though, as Tensors have no notion of "base address" 😅
Taking a step back, we should probably rename the input arguments as:
index
->offsets
index_vec
->indices
Have you thought about it?
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.
@banach-space Thanks for the feedback, and apologies for landing this faster than necessary. Let me know if you think this can be improved further and I'll definitely make a follow-up PR.
With respect to
I find interpreting base as a pointer less clear.
Exactly!
I'll add that memrefs can be strided (see this test so should strides be included?
Another subtle difference is what 'out of bounds' means. Current lowering ends up as vector.loads of single elements
There is nothing in the vector.load definition about out-of-bounds, but I assume the natural definition there would be that if %j excedes 99 above, it's out of bounds a UB. Which I think is more inline with the current definition of adding index_vec[i,j] to i2.
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.
No worries - this was in review for two days and two reviewers approved it, so it’s totally expected that you landed it. But since post-commit reviews are a thing in LLVM, and this is interesting... 😅
Fair enough!
Hm, not at the
vector.gather
norVector
level, no. Are they?UB sounds about right. Masks should take care of "out-of-bounds". If they don't, it would be a UB, yes. Admittedly, we haven't paid that much attention to gathers/scatters - performance is not great and we try to avoid them.
Uh oh!
There was an error while loading. Please reload this page.
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 meant, in that test (copied below)
if the explanation of vector.gather was pointer based:
then we should probably include a stride in the above. i.e. it should
+ index_vec[i,j]
should be+ stride * index_vec[i,j]
This is one reason why I think the pointer-based definition of gather a bit less clear. With the tensor-based definition (just add index_vec[i,j] to another index, not a pointer) this question doesn't come up.
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.
Sorry for not replying earlier, I was OOO.
I view this differently. To me,
base[i0, i1, i2] + index_vec[i,j]
is thevector
abstraction and that's all we care about here. Later, thesevector
level indices are interpreted at either thememref
ortensor
abstraction levels - that's when "stride" would matter. Put differently, I agree that the actual meaning of this will depend on whatbase
is:However, to me that should not be a concern at the
vector
level.Anyway, this is a side point - it's obviously totally fine to see things differently. Your change is a much appreciated improvement, lets leave it as is.