search

riscv-non-isa / rvv-intrinsic-doc

https://jira.riscv.org/browse/RVG-153
BSD 3-Clause "New" or "Revised" License
284 stars 89 forks source link

Clarify the consequences of vxsat not being handled by the intrinsics #318

Closed rofirrim closed 5 months ago

rofirrim commented 5 months ago

As pointed by the ARC review it is acceptable that we leave out the vxsat support for a 1.0 version of the specification but we should clarify the consequences. The spec already contains a reference to this but it seems reasonable to expand on the consequences.

In summary: The specification does not provide a mechanism to read vxsat or update it in a predictable way using a sequence of fixed point arithmetic intrinsics.

rofirrim commented 5 months ago

Earl Killian from ARC suggests that

Might I suggest that you specify for the intrinsics that would affect vxsat, that vxsat is UNSPECIFIED after execution of the intrinsic (to allow forward compatibility with whatever may or may not be done on the future to more properly support vxsat)?

dzaima commented 5 months ago

As a side-note, I wonder if it even makes sense for intrinsics to state anything about the vxsat CSR - clang already can autovectorize plain scalar code to vxsat-modifying code, so it's already the case that basic regular C arithmetic can modify vxsat, thus making intrinsics also doing such moot.

nick-knight commented 5 months ago

@dzaima I agree with a more general comment, that this API spec doesn't need to discuss any of the V-extension architectural state, in the same way that the C language specification of <fenv> doesn't mention frm and fflags. Said differently, you could write a C compiler that retargets RVV intrinsics at a non-RVV ISA, emulating everything.

This type of discussion might be relevant in an ABI document, or a document about mixing RVV intrinsics and inline asm, but the RVV intrinsics spec (intentionally) avoids both of these topics.

In the case of this PR, we are responding to a request from the RVI Architecture Review Committee that is blocking ratification of this spec. Rather than philosophizing and bickering with the ARC about what truly belongs in a C API spec, we decided it was more expedient to just simply implement their request, which amounts to expanding a (non-normative!) note that existed already.