[Bug target/112817] RISC-V: RVV: provide a preprocessor macro for VLS codegen

2024-01-08 Thread vineetg at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817

--- Comment #9 from Vineet Gupta  ---
(In reply to JuzheZhong from comment #5)
> Support VLS codegen with -mrvv-vector-bits and attribute is reasonable to be
> landed on GCC-14.
> 
> Could you first implement -mrvv-vector-bits feature ?
> 
> I have support it in rvv-next, but I don't have time to migrate that into
> trunk GCC.

I presume you are referring to https://github.com/riscv-collab/riscv-gcc.git
and #riscv-gcc-rvv-next

I don't see the attribute support. Is it called something else there ?

I was looking for a new entry in gcc/c-family/c-attribs.cc or would be
somewhere else.

[Bug target/112817] RISC-V: RVV: provide a preprocessor macro for VLS codegen

2023-12-05 Thread kito at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817

Kito Cheng  changed:

   What|Removed |Added

 CC||kito at gcc dot gnu.org

--- Comment #8 from Kito Cheng  ---
This topic has raised at last RISC-V GCC sync meeting, and one action item for
me is chat with JuzheZhong about -mrvv-vector-bits=zvl / __riscv_v_fixed_vlen /
riscv_rvv_vector_bits stuffs

[Bug target/112817] RISC-V: RVV: provide a preprocessor macro for VLS codegen

2023-12-01 Thread juzhe.zhong at rivai dot ai via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817

--- Comment #7 from JuzheZhong  ---
(In reply to Vineet Gupta from comment #6)
> (In reply to JuzheZhong from comment #5)
> 
> > Support VLS codegen with -mrvv-vector-bits and attribute is reasonable to be
> > landed on GCC-14.
> 
> I don't think that is the reqmt for this issue. Just defining the
> preprocessor flag with existing gcc toggle for VLS codegen should be enough
> - as long as it generates same macro as llvm.

So, what do you mean ? I don't understand.
If you doesn't need attribute, how to fix the issue.

[Bug target/112817] RISC-V: RVV: provide a preprocessor macro for VLS codegen

2023-12-01 Thread vineetg at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817

--- Comment #6 from Vineet Gupta  ---
(In reply to JuzheZhong from comment #5)

> Support VLS codegen with -mrvv-vector-bits and attribute is reasonable to be
> landed on GCC-14.

I don't think that is the reqmt for this issue. Just defining the preprocessor
flag with existing gcc toggle for VLS codegen should be enough - as long as it
generates same macro as llvm.

[Bug target/112817] RISC-V: RVV: provide a preprocessor macro for VLS codegen

2023-12-01 Thread juzhe.zhong at rivai dot ai via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817

--- Comment #5 from JuzheZhong  ---
Support VLS codegen with -mrvv-vector-bits and attribute is reasonable to be
landed on GCC-14.

But currently we are busy with fixing bugs (me, Robin, Lixu@eswin, Li
Pan@intel).
You can see gcc-patch list...


Could you first implement -mrvv-vector-bits feature ?

I have support it in rvv-next, but I don't have time to migrate that into trunk
GCC.

[Bug target/112817] RISC-V: RVV: provide a preprocessor macro for VLS codegen

2023-12-01 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817

--- Comment #4 from Andrew Pinski  ---
(In reply to Vineet Gupta from comment #3)
> I agree, but what xsimd does is not under our control. Whoever wants to use
> xsimd for whatever reasons, we can allow gcc to be used similarly to llvm
> and certainly not for lack of a trivial define.

What I am trying to say is almost all of these "SIMD" libraries were done to
wrap x86_64 SIMD and is almost done in a bad form in general. I noticed that
when working on AARCH64 (even before SVE). they push the idea of a low level
wrapper just because "it is easier" rather than higher level concepts. xsimd,
even the whole C++ SIMD library seems to push low level wrappers rather than
high level concepts that could be optimized.

[Bug target/112817] RISC-V: RVV: provide a preprocessor macro for VLS codegen

2023-12-01 Thread vineetg at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817

Vineet Gupta  changed:

   What|Removed |Added

 CC||vineetg at gcc dot gnu.org

--- Comment #3 from Vineet Gupta  ---
I agree, but what xsimd does is not under our control. Whoever wants to use
xsimd for whatever reasons, we can allow gcc to be used similarly to llvm and
certainly not for lack of a trivial define.

[Bug target/112817] RISC-V: RVV: provide a preprocessor macro for VLS codegen

2023-12-01 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817

--- Comment #2 from Andrew Pinski  ---
Note the reality is xsimd was not thought out for SIMD but rather just fixed
length extensions. It seems more like a major shift that needs to happen to
these libraries and stop just thinking fixed length registers.

[Bug target/112817] RISC-V: RVV: provide a preprocessor macro for VLS codegen

2023-12-01 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817

--- Comment #1 from Andrew Pinski  ---
>gcc doesn't, which is a bit of pain for downstream projects such as xsimd.

Does it even make sense to define this? Projects like xsimd seems to be good
for fixed length SIMD but it seems to have a broken idea for non-fixed length
SIMD like SVE and RVV. Would it better to have xsimd provide better interfaces
instead for non-fixed length vectors and not provide a fixed length API at all?

[Bug target/112817] RISC-V: RVV: provide a preprocessor macro for VLS codegen

2023-12-01 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement