You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is currently not possible (on gcc and clang) to use the vector intrinsics in functions with a target attribute that adds vector support, if it vector support wasn't also enabled globally.
This is needed for implementing dynamic dispatch in the same translation unit, as e.g. used in simdutf.
The current compiler implementations aren't wrong to only allow including <riscv_vector.h> and defining __riscv_v_intrinsic, when the vector extension is enabled globally, but I think we should encourage implementations to view __riscv_v_intrinsic and __riscv_vector separately, when possible.
Something along the lines of "__riscv_v_intrinsic being defined doesn't guarantee that __riscv_vector is also defined."
From what I can tell this isn't required by the spec anywhere, but implementers assumed the opposite is implied.
The __riscv_v_intrinsic macro is the C macro to test the compiler’s support for the RISC-V "V" extension intrinsics
__riscv_vector [...] Implies that any of the vector extensions (v or zve*) is available
This would suggest, that __riscv_v_intrinsic does not automatically imply __riscv_vector is defined.
The text was updated successfully, but these errors were encountered:
For clang this needs a lot of work. For example, the code in SemaChecking.cpp that checks for valid rvv vector types is completely unaware of the existence of attribute((target)).
It is currently not possible (on gcc and clang) to use the vector intrinsics in functions with a target attribute that adds vector support, if it vector support wasn't also enabled globally.
This is needed for implementing dynamic dispatch in the same translation unit, as e.g. used in simdutf.
The current compiler implementations aren't wrong to only allow including
<riscv_vector.h>
and defining__riscv_v_intrinsic
, when the vector extension is enabled globally, but I think we should encourage implementations to view__riscv_v_intrinsic
and__riscv_vector
separately, when possible.Something along the lines of "
__riscv_v_intrinsic
being defined doesn't guarantee that__riscv_vector
is also defined."From what I can tell this isn't required by the spec anywhere, but implementers assumed the opposite is implied.
This would suggest, that
__riscv_v_intrinsic
does not automatically imply__riscv_vector
is defined.The text was updated successfully, but these errors were encountered: