Comments (11)
I'm happy too.
As Kai mentioned above I suggested the opaque approach in the light of some concerns about arbitrary arithmetic on vl
.
However the typical uses of the value returned by the vsetvl
may become too annoying if we make it an opaque type. For instance advancing the induction variable in a strip-mined loop.
I think we should not be obsessed by trying to protect the user of "bad vl values" (= not the result of a previous vsetvl
) as those might slip in as well if using an operation where LMUL/SEW changes.
For instance a vsetvl
could have used SEW=32 but accidentally be used on a SEW=64 operation and neither explicit or implicit vl
is going to help us here. Don't get me wrong: a programming language could provide safer mechanisms, it is just that C and intrinsics may not be the right level of abstraction to provide those.
Thanks @Hsiangkai !
from rvv-intrinsic-doc.
I have removed the opaque type in the document.
from rvv-intrinsic-doc.
from rvv-intrinsic-doc.
from rvv-intrinsic-doc.
No, but the 'opaque' still appears in the current draft so I figured I'd bring up the issue so it could be cleared up...
from rvv-intrinsic-doc.
Sorry for reply late. My understanding is we agreed to have an opaque type for VL argument. The design is related to whether we permit users to manipulate VL argument or not. We could remove the opaque type for VL and only add recommendation for users to avoid using arithmetics on vl arguments.
from rvv-intrinsic-doc.
I don't agree :-) As I tried to explain in this ticket, the very point of the VL parameter in intrinsic is lost if VL is opaque... (and i'm still not sold on the 2/3-defined intrinsics either ;-) )
I also don't see the problem of doing arithmetic with VL. For instance, once you get the usable VL from vsetvl(), you can tune e.g. the size of a sparse matrix block to that VL, or be able to compute the 'proper' number of iterations for cache blocking. Knowing how much data you deal with is a cornerstone of many optimizations/tuning strategies.
The only issue passing an arbitrary VL to an intrinsic is you don't get the actual value back, so the programmer needs to make sure it's legit. But that's not harder than any other restriction in the value of parameters (e.g. limited range of immediate, etc.).
from rvv-intrinsic-doc.
In my point of view, intrinsics with vl argument have the same semantics with intrinsics without vl argument. That is why SiFive proposes intrinsics without vl argument. If you expect intrinsics with vl argument help you to change vl temporarily, you combine vsetvl and v-operations into one intrinsic. The semantic will be different from the underlying assembly code. Intrinsics with vl argument just show the relationship between vsetvl intrinsics and other vector intrinsics. Using opaque VL type could ensure these two flavors of intrinsics have the same semantics.
As mentioned in this comment[1], using intrinsics with vl argument to change vl is syntactic sugar. You could use extra invocation of vsetvl intrinsics to achieve the same goal.
Intrinsics without vl argument is not 2/3 defined intrinsics. SEW and LMUL should be a part of the instructions. If encoding space is big enough, they will be encoded into the instructions as mentioned in 3.3 in V specification[2].
“It is anticipated that an extended 64-bit instruction encoding would allow these fields to be specified statically in the instruction encoding.”
However, VL argument could not be encoded into the instructions. It is a parameter provided by users. It looks like all these three parameters are variables for the instructions. In reality, SEW and LMUL is the static part of the execution context and VL is the dynamic part of the execution context. They are different.
[1] https://github.com/sifive/rvv-intrinsic-doc/issues/8#issuecomment-615358742
[2] https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#33-vector-type-register-vtype
from rvv-intrinsic-doc.
you combine vsetvl and v-operations into one intrinsic.
Exactly. Which is why forcing an opaque type on the parameter is absurd - it can be seen as a shorthand (I see it as 'pure function with fully defined semantic' ;-) ). Except with an opaque type, you still need the vsetvl in scope, which defeat the point of the shorthand. And make 'normal' usage (i.e. the example in this issue where the result of vsetvl is used as the iteration variable increment) more painful for no reason whatsoever.
It's still possible to extract VL for the opaque type (otherwise the loop in my example become really tricky to implement, and it's already basically the easiest case), do some arithmetic, and feed it back in vsetvl, so it doesn't even stop doing what the hardware people don't want the software people to do for no clear motive that I can see.
[most of the following should probably be in #8 not in #20...]
using intrinsics with vl argument to change vl is syntactic sugar
Except it also make a single intrinsic fully-defined, and not reliant on some hidden state. It's not all about writability, it's also about readability. Having all relevant parameters visible in one spot is good. Hidden states are a recipe for trouble, in particular when 2/3 are explicit and 1/3 isn't (both LMUL and SEW, despite being part of the hidden state, are visible in the intrinsic).
In reality, SEW and LMUL is the static part of the execution context and VL is the dynamic
part of the execution context. They are different.
Yes, they are. That's why it's fine for two of them to be in the intrinsic name, and the third one as a parameter; as you said, two are essentially static (although, theoretically, one might want to write a precision-agnostic loop by leveraging SEW...), while one is dynamic. It's a justification to specify them differently, but not a justification so specify only some of them.
I'm OK with people insisting they don't need VL in intrinsics, even though it feels wrong to me; to each its own. I'm not OK with trying to cripple the VL-specifying version by forcing some artificial opacity in a context where we're working as close as the hardware as possible without actually writing assembly.
from rvv-intrinsic-doc.
I am fine to remove the type constraint. Intrinsics with vl is proposed by @rofirrim and @rofirrim proposed the opaque type for vl after discussion. If @rofirrim does not oppose the suggestion, we could remove the constraint.
from rvv-intrinsic-doc.
Thanks :-)
from rvv-intrinsic-doc.
Related Issues (20)
- Does `__riscv_v_intrinsic >= 1000000` imply overloaded intrinsics are supported?
- Create bibliography from reference section HOT 3
- Simple questions about inline assembly in vmv.x.s instruction HOT 2
- Asterisks are not subscripts
- the wrong result of "vmerge_vvm_i32m1" HOT 5
- ta,ma reduction destination with vl=0 HOT 1
- Clarify the consequences of vxsat not being handled by the intrinsics HOT 3
- Add a section with examples HOT 3
- Rename uses of {implicit,explicit}-frm into {Implicit, Explicit} FP rounding mode HOT 1
- Clarify the mapping of pseudo-intrinsics
- Clarify what float and double means HOT 1
- Fix authors in the document
- How to use LMUL in rvv-intrinsic? HOT 6
- Mismatched bfloat16 autogenerated files HOT 3
- Freeze the specification HOT 1
- `vfirst` and `vcpop` return types unexpectedly changed HOT 1
- Renaming the VL arguments to AVL HOT 4
- Should bf16 vmv.v.v and vmerge.vvm be supported with Zvfbfmin? HOT 1
- Should f16 vrgather/vcompress be supported for f16 with Zvfhmin? bf16 with Zvfbfmin? HOT 1
- Should f16 vundefined/lmul_ext/lmul_trunc/vget/vset/vcreate be support with Zvfhmin HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rvv-intrinsic-doc.