Drop opacity of VL

[riscv-non-isa]

Drop opacity of VL

[rofirrim]

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 !

[Hsiangkai]

I have removed the opaque type in the document.

[ebahapo]

Folks, At this point, when the V extension and this draft are still prototypes, I'd be fine with more laxity at this time. It may change as people get more experience using these intrinsics, but it's a reasonable request to not constrain the type of the argument for VL. It may be a special type, but it should be allowed conversion back and forth to an integer for now. Just my 2¢.

…

__ Evandro Menezes ◊ SiFive ◊ Austin, TX

[ebahapo]

Hi, Romain. Unless I'm not following you, this seems like we have discussed this before. It is my understanding that we agreed to have a non opaque type for VL and both implicit and explicit builtins. Or are you proposing something else? Thank you,

…

__ Evandro Menezes ◊ SiFive ◊ Austin, TX

On May 19, 2020, at 2:55, Romain Dolbeau ***@***.***> wrote: Having VL an opaque type adds useless complexity to the general case, and is not justified in any way beyond "To avoid users to manipulate vl argument in explicit vl intrinsic", which doesn't make sense. The point of explicit VL in instrinsics is to be able to avoid vsetvl for short-term change. If it's needed to get the proper opaque type, what's the point? A typical way of writing this: for (i = 0; i<n;i++) { c[i]=a[i]+b[i]; } would be (not the proper syntax to save time) while (i < n) { unsigned long vl = vsetvl(n - i); vtype va = vload(a+i, vl); vtype vb = vload(b+i, vl); vtype vc = vadd(va, vb, vl); vstore(c+i, vc, vl); i +=vl; } Forcing an opaque type on vl will add complexity by forcing an unexpected type on vl (it is semantically a number after all...). The point of an explicit VL is that this: vsetvl(X); vop(a,b); can be shortened to this and the intrinsics be made fully specified (and not just 2 out of the 3 implicit values); vop(a,b,X); If a vsetvl is needed the it's useless. To summarize: a) with only non-fully-specified (VL-less) intrinsic, opacity adds complexity and brings nothing b) with full-specified intrinsics, it defeats the point by forcing vsetvl() where none is needed ot wanted — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/sifive/rvv-intrinsic-doc/issues/20>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFZIEAOAJUZUKLCKID3RYZDRSI3OLANCNFSM4NEYFVDQ>.

[rdolbeau]

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...

[Hsiangkai]

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.

[rdolbeau]

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.).

[Hsiangkai]

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

[rdolbeau]

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.

[Hsiangkai]

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.

[rdolbeau]

Thanks :-)