Conversation
Previously vscale_range used to add the constraint that vscale is a power-of-two, but after llvm#183080 it's already a power-of-two to begin with. This drops the extra mention of power-of-two to clarify it's not a new constraint now.
|
@llvm/pr-subscribers-llvm-ir Author: Luke Lau (lukel97) ChangesPreviously vscale_range used to add the constraint that vscale is a This drops the extra mention of power-of-two to clarify it's not a new Full diff: https://github.com/llvm/llvm-project/pull/183689.diff 1 Files Affected:
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 2f5ba6c22ddab..4142e496cdbe2 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -2771,12 +2771,12 @@ For example:
than `UINT_MAX`. It's unspecified which threshold will be used when
duplicate definitions are linked together with differing values.
``vscale_range(<min>[, <max>])``
- This function attribute indicates `vscale` is a power-of-two within a
- specified range. `min` must be a power-of-two that is greater than 0. When
- specified, `max` must be a power-of-two greater-than-or-equal to `min` or 0
- to signify an unbounded maximum. The syntax `vscale_range(<val>)` can be
- used to set both `min` and `max` to the same value. Functions that don't
- include this attribute make no assumptions about the value of `vscale`.
+ This function attribute indicates `vscale` is within a specified
+ range. `min` must be a power-of-two that is greater than 0. When specified,
+ `max` must be a power-of-two greater-than-or-equal to `min` or 0 to signify
+ an unbounded maximum. The syntax `vscale_range(<val>)` can be used to set
+ both `min` and `max` to the same value. Functions that don't include this
+ attribute make no assumptions about the range of `vscale`.
``nooutline``
This attribute indicates that outlining passes should not modify the
function.
|
|
Please can we keep the explicitness here? I don't see a problem with being more verbose. Also, while there's an option, however unlikely, of walking back the "vscale is a power-of-two" decision, this would not apply to |
My concern is that we have places where we checked vscale_range to get the power-of-2 guarantee, and I don't want developers to read the vscale_range part in the LangRef and think it's still needed. It's not a major concern though, dropped from this PR. I've still kept the update to the "make no assumptions about the value of vscale" part though since I don't think that's accurate anymore |
…ut the attribute (llvm#183689) Previously vscale_range used to add the constraint that vscale is a power-of-two, but after llvm#183080 it's already a power-of-two to begin with. This clarifies the sentence about assumptions when there is no attribute
Previously vscale_range used to add the constraint that vscale is a
power-of-two, but after #183080 it's already a power-of-two to begin with.
This clarifies the sentence about assumptions when there is no attribute