[FFmpeg-devel] [PATCH] libswscale/riscv: Fix syntax of vsetvli

[Rémi Denis-Courmont]

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/