Le maanantaina 3. heinäkuuta 2023, 18.52.13 EEST Khem Raj a écrit : > > *Hopefully* LLVM gets their act together by release 16, and ship a usable > > assembler, rather than tell us to use automatic RVV vectorisation (which > > *is* a release 16 feature, though it was half-baked last time I tried). > I am on clang/llvm trunk ( future 17.0 release ), I will also open an > issue with llvm on github regarding this.
If I were you, I would first open an issue on the riscv-v-spec Github to seek clarification (though I'm not sure if it's open for bug submission?). > > >Fixes building with clang > > > > More like bug-compatible work-around than fix, AFAIU. > > I can do it although I did not find a relevant section in spec about > these being optional, I did see examples omitting them though. > > > >| src/libswscale/riscv/rgb2rgb_rvv.S:88:25: error: operand must be > > >| e[8|16|32|64|128|256|512|1024],m[1|2|4|8|f2|f4|f8],[ta|tu],[ma|mu]> > > Do you have a reference to the Github RVV spec to validate this, that I > > overlooked, or it's just misled and misleading spew from LLVM? > Perhaps the latter but I also did not see reference to the former. > Here is a small example > > a.S > #.option arch, +zve32x > # OK > #vsetvli t4, t3, e8, m1, ta, ma > # BAD > vsetvli t4, t3, e8, ta, ma > > clang -target riscv64 -march=rv64izve32x1p0 a.S -c Well, yes but the idea is to keep V disabled in the target flags, and do run- time detection... Especially so far, while RVV hardware remains unobtainium, the compiler can't assume that V is supported, or else... And so LLVM AS has been so far unusable for both FFmpeg and kernel alike. -- 雷米‧德尼-库尔蒙 http://www.remlab.net/ _______________________________________________ ffmpeg-devel mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
