[LangRef] Update the semantic of experimental.get.vector.length
#104475
Conversation
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
The previous semantics of `llvm.experimental.get.vector.length` was too permissive such that it gave optimizers a hard time on anything related to the number of iterations of VP-vectorized loops. This patch tries to address this by assigning it a set of stricter semantics similar to that of RVV's VSETVLI instructions, while being not too RISC-V specific and leaving room for other (future) targets. Co-authored-by: Craig Topper <[email protected]>
|
@llvm/pr-subscribers-llvm-ir Author: Min-Yih Hsu (mshockwave) ChangesThe previous semantics of This patch tries to address this by assigning it a set of stricter semantics similar to that of RVV's VSETVLI instructions, while being not too RISC-V specific and leaving room for other (future) targets. Full diff: https://github.com/llvm/llvm-project/pull/104475.diff 1 Files Affected:
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 5e5e9b9e8a93b1..22fd805a4685b1 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -19644,13 +19644,19 @@ in order to get the number of elements to process on each loop iteration. The
result should be used to decrease the count for the next iteration until the
count reaches zero.
-If the count is larger than the number of lanes in the type described by the
-last 2 arguments, this intrinsic may return a value less than the number of
-lanes implied by the type. The result will be at least as large as the result
-will be on any later loop iteration.
-
-This intrinsic will only return 0 if the input count is also 0. A non-zero input
-count will produce a non-zero result.
+Let ``%max_lanes`` be the number of lanes in the type described by ``%vf`` and
+``%scalable``, here are the constraints on the returned value:
+- If ``%cnt`` equals to 0, returns 0.
+- The returned value is always less or equal to ``%max_lanes``.
+- The returned value is always larger or equal to
+ ``ceil(%cnt / ceil(%cnt / %max_lanes))``.
+ - This implies that if ``%cnt`` is non-zero, the result should be non-zero
+ as well.
+ - This also implies that if ``%cnt`` is less than ``%max_lanes``, it has to
+ return ``%cnt``.
+- The returned values decrease monotonically in each loop iteration. That is,
+ the returned value of a iteration is at least as large as that of any later
+ iterations.
'``llvm.experimental.vector.partial.reduce.add.*``' Intrinsic
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
topperc
approved these changes
Aug 15, 2024
frasercrmck
reviewed
Aug 19, 2024
| Let ``%max_lanes`` be the number of lanes in the type described by ``%vf`` and | ||
| ``%scalable``, here are the constraints on the returned value: | ||
| - If ``%cnt`` equals to 0, returns 0. | ||
| - The returned value is always less or equal to ``%max_lanes``. |
There was a problem hiding this comment.
I'd probably say "less than or equal to"
ayalz
reviewed
Aug 19, 2024
| count will produce a non-zero result. | ||
| - If ``%cnt`` equals to 0, returns 0. | ||
| - The returned value is always less than or equal to ``%max_lanes``. | ||
| - The returned value is always greater than or equal to ``ceil(%cnt / ceil(%cnt / %max_lanes))``. |
There was a problem hiding this comment.
Suggested change
| - The returned value is always greater than or equal to ``ceil(%cnt / ceil(%cnt / %max_lanes))``. | |
| - The returned value is always greater than or equal to ``ceil(%cnt / ceil(%cnt / %max_lanes))``, if ``%cnt`` is non-zero. |
| - If ``%cnt`` equals to 0, returns 0. | ||
| - The returned value is always less than or equal to ``%max_lanes``. | ||
| - The returned value is always greater than or equal to ``ceil(%cnt / ceil(%cnt / %max_lanes))``. | ||
| - The returned values decrease monotonically in each loop iteration. That is, |
There was a problem hiding this comment.
Suggested change
| - The returned values decrease monotonically in each loop iteration. That is, | |
| - The returned values are monotonically non-increasing in each loop iteration. That is, |
| - The returned value is always less than or equal to ``%max_lanes``. | ||
| - The returned value is always greater than or equal to ``ceil(%cnt / ceil(%cnt / %max_lanes))``. | ||
| - The returned values decrease monotonically in each loop iteration. That is, | ||
| the returned value of a iteration is at least as large as that of any later |
There was a problem hiding this comment.
Suggested change
| the returned value of a iteration is at least as large as that of any later | |
| the returned value of an iteration is at least as large as that of any later |
| - The returned value is always greater than or equal to ``ceil(%cnt / ceil(%cnt / %max_lanes))``. | ||
| - The returned values decrease monotonically in each loop iteration. That is, | ||
| the returned value of a iteration is at least as large as that of any later | ||
| iterations. |
There was a problem hiding this comment.
Suggested change
| iterations. | |
| iteration. |
|
|
||
| Note that it has the following implications: | ||
|
|
||
| - If ``%cnt`` is non-zero, the result should be non-zero as well. |
There was a problem hiding this comment.
Suggested change
| - If ``%cnt`` is non-zero, the result should be non-zero as well. | |
| - If ``%cnt`` is non-zero, the return value is non-zero as well. |
| Note that it has the following implications: | ||
|
|
||
| - If ``%cnt`` is non-zero, the result should be non-zero as well. | ||
| - If ``%cnt`` is less than ``%max_lanes``, it has to return ``%cnt``. |
There was a problem hiding this comment.
Suggested change
| - If ``%cnt`` is less than ``%max_lanes``, it has to return ``%cnt``. | |
| - If ``%cnt`` is less than or equal to ``%max_lanes``, the return value is equal to ``%cnt``. |
| iterations. | ||
|
|
||
| Note that it has the following implications: | ||
|
|
There was a problem hiding this comment.
Suggested change
| - The number of iterations is equal to ``ceil(%cnt / %max_lanes)``. |
right?
There was a problem hiding this comment.
That's correct, though since the %cnt value is decreased in every iteration, I phrase it slightly differently now.
5c4lar
pushed a commit
to 5c4lar/llvm-project
that referenced
this pull request
Aug 29, 2024
…vm#104475) The previous semantics of `llvm.experimental.get.vector.length` was too permissive such that it gave optimizers a hard time on anything related to the number of iterations of VP-vectorized loops. This patch tries to address this by assigning it a set of stricter semantics similar to that of RVV's VSETVLI instructions, while being not too RISC-V specific and leaving room for other (future) targets. --------- Co-authored-by: Craig Topper <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The previous semantics of
llvm.experimental.get.vector.lengthwas too permissive such that it gave optimizers a hard time on anything related to the number of iterations of VP-vectorized loops.This patch tries to address this by assigning it a set of stricter semantics similar to that of RVV's VSETVLI instructions, while being not too RISC-V specific and leaving room for other (future) targets.