[FFmpeg-devel] [PATCH 1/4] configure: aarch64: Support assembling the dotprod and i8mm arch extensions

[Rémi Denis-Courmont]

Le perjantaina 26. toukokuuta 2023, 11.03.12 EEST Martin Storsjö a écrit :
> These are available since ARMv8.4-a and ARMv8.6-a respectively,
> but can also be available optionally since ARMv8.2-a.
> 
> Check if these are available for use unconditionally (e.g. if compiling
> with -march=armv8.6-a), or if they can be enabled with specific
> assembler directives.
> 
> Use ".arch_extension <ext>" for enabling a specific extension in
> assembly; the same can also be achieved with ".arch armv8.2-a+<ext>",
> but with .arch_extension is easier to combine multiple separate
> features.
> 
> Enabling these extensions requires setting a base architecture level
> of armv8.2-a with .arch. Don't add ".arch armv8.2-a" unless necessary;
> if the base level is high enough (which might unlock other extensions
> without .arch_extension), we don't want to lower it.

I don't follow how that would actually happen, TBH. Even if the default target 
version is, say, 8.5, the assembler won't magically start emitting 8.5 
instructions.

Someone would have to write assembler code that would fail to build under a 
toolchain with a lower target version. That sounds like a bug that should be 
spotted and fixed, rather than papered over. Conversely the logic here seems 
unnecessarily, if not counter-productively, intricate.

> Only add .arch/.arch_extension if needed, e.g. current clang fails
> to recognize the dotprod and i8mm features in .arch_extension, but
> can successfully assemble these instructions if part of the baseline
> set with -march.

IME, Clang is utterly useless for assembling. That has become one of my pet 
peeves with Rust inline assembler, which is other much nicer than C inline 
assembler, whence you can't just work around it with `-no-integrated-as`. But 
I digress.

If the problem is to avoid `.arch_extension`, then I don't really see why you 
can't just use `.arch` with plus, and simplify a lot.


-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/