Loading README.md +10 −16 Changes for README.md: 10 added lines, 16 removed lines. Original line number Diff line number Diff line Loading @@ -27,7 +27,7 @@ low-level builtins. ## Documentation These builtins targets the 0.9 version of the extension. The implementation These builtins targets the 1.0 version of the extension. The implementation is not complete and there are known limitations. See section _Known limitations_ below. Loading Loading @@ -57,10 +57,10 @@ on the compiler to fold the broadcasted operand when possible. This way we avoid duplicating all the builtins. The `rvv-intrin.h` header would be responsible of providing the versions with a scalar operand. In EPI we are currently targeting `ELEN=64` and `VLEN=SLEN` so the widest types that fit in a register are `__epi_1xi64` and `__epi_1xf64`. All the other types with narrower elements have their number of elements scaled: `__epi_2xi32`, `__epi_2xf32`, `__epi_4xi16`, etc. In EPI we are currently targeting `ELEN=64` so the widest types that fit in a register are `__epi_1xi64` and `__epi_1xf64`. All the other types with narrower elements have their number of elements scaled: `__epi_2xi32`, `__epi_2xf32`, `__epi_4xi16`, etc. Vector types are dependent on `ELEN`. For instance, `__epi_2xi32` when targeting `ELEN=64` will be compiled to code that uses `LMUL=1`. That same type, though, Loading @@ -68,14 +68,7 @@ will be compiled to code that uses `LMUL=2` when targeting `ELEN=32`. ## Known limitations We are still incomplete in several aspects. The extensions `Zvamo` and `Zvediv` and `Zvlsseg` have not been considered in the current definition of builtins. There are no extending loads or truncating store builtins. Exposing semantically equivalent operations like `fmacc` vs `fmadd` doesn't seem useful. A single `fma` builtin should be available so the compiler has freedom to choose the best instuction. Not all the RVV 1.0 instructions are accessible from these intrinsics. ## Related work Loading @@ -86,6 +79,7 @@ to LLVM to support the SVE architecture. This work has been done as part of the European Processor Initiative project. The European Processor Initiative (EPI) (FPA: 800928) has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement EPI-SGA1: 826647 The European Processor Initiative (EPI) has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement EPI-SGA1: 826647 and under EPI-SGA2: 101036168. Please see http://www.european-processor-initiative.eu for more information. epi-builtins-ref.md +1478 −1432 File changed.Preview size limit exceeded, changes collapsed. Show changes Loading
README.md +10 −16 Changes for README.md: 10 added lines, 16 removed lines. Original line number Diff line number Diff line Loading @@ -27,7 +27,7 @@ low-level builtins. ## Documentation These builtins targets the 0.9 version of the extension. The implementation These builtins targets the 1.0 version of the extension. The implementation is not complete and there are known limitations. See section _Known limitations_ below. Loading Loading @@ -57,10 +57,10 @@ on the compiler to fold the broadcasted operand when possible. This way we avoid duplicating all the builtins. The `rvv-intrin.h` header would be responsible of providing the versions with a scalar operand. In EPI we are currently targeting `ELEN=64` and `VLEN=SLEN` so the widest types that fit in a register are `__epi_1xi64` and `__epi_1xf64`. All the other types with narrower elements have their number of elements scaled: `__epi_2xi32`, `__epi_2xf32`, `__epi_4xi16`, etc. In EPI we are currently targeting `ELEN=64` so the widest types that fit in a register are `__epi_1xi64` and `__epi_1xf64`. All the other types with narrower elements have their number of elements scaled: `__epi_2xi32`, `__epi_2xf32`, `__epi_4xi16`, etc. Vector types are dependent on `ELEN`. For instance, `__epi_2xi32` when targeting `ELEN=64` will be compiled to code that uses `LMUL=1`. That same type, though, Loading @@ -68,14 +68,7 @@ will be compiled to code that uses `LMUL=2` when targeting `ELEN=32`. ## Known limitations We are still incomplete in several aspects. The extensions `Zvamo` and `Zvediv` and `Zvlsseg` have not been considered in the current definition of builtins. There are no extending loads or truncating store builtins. Exposing semantically equivalent operations like `fmacc` vs `fmadd` doesn't seem useful. A single `fma` builtin should be available so the compiler has freedom to choose the best instuction. Not all the RVV 1.0 instructions are accessible from these intrinsics. ## Related work Loading @@ -86,6 +79,7 @@ to LLVM to support the SVE architecture. This work has been done as part of the European Processor Initiative project. The European Processor Initiative (EPI) (FPA: 800928) has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement EPI-SGA1: 826647 The European Processor Initiative (EPI) has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement EPI-SGA1: 826647 and under EPI-SGA2: 101036168. Please see http://www.european-processor-initiative.eu for more information.
epi-builtins-ref.md +1478 −1432 File changed.Preview size limit exceeded, changes collapsed. Show changes
