Hi, On Thu, Jul 26, 2012 at 4:52 PM, Ronald S. Bultje <[email protected]> wrote: > On Thu, Jul 26, 2012 at 3:54 PM, Diego Biurrun <[email protected]> wrote: >> On Thu, Jul 26, 2012 at 03:42:24PM -0700, Ronald S. Bultje wrote: >>> On Thu, Jul 26, 2012 at 2:39 PM, Diego Biurrun <[email protected]> wrote: >>> > On Thu, Jul 26, 2012 at 01:50:17PM -0700, Ronald S. Bultje wrote: >>> >> >>> >> discussion thread. We currently use HAVE_SSSE3 and related macros to >>> >> indicate that we want to compile these and that our compiler tools are >>> >> good enough to know what to do with it. As a result, we currently use >>> >> HAVE_AVX around all avx code (yasm only - we don't have any avx inline >>> >> asm), HAVE_SSSE3 around some yasm and all inline asm code that uses >>> >> ssse3 instructions, and sometimes HAVE_SSE/2 around inline asm using >>> >> xmm regs. There is no HAVE_SSE4. HAVE_MMX2 is almost never used but >>> >> does exist. >>> > >>> > Do we need HAVE_SSE4? It should be easy enough to add. >>> > >>> >> HAVE_MMX is something entirely different and is used as an >>> >> alternative form of ARCH_X86. >>> > >>> > No, HAVE_MMX is just that. True, it's abused in some places where >>> > ARCH_X86 would be better (when invoking init functions), but that >>> > is an issue that needs to be addressed at some point. >>> > >>> >> In addition to that, we're using inline asm checks to test whether to >>> >> enable HAVE_SSSE3 and HAVE_SSE2 (line 2850 of configure). >>> >> >>> >> Can we split these macros in something for yasm vs something for >>> >> inline asm? This means e.g. that we can use ssse3 if yasm (but not >>> >> inline asm) supports it, if inline asm is lacking, etc. >>> > >>> > What is your goal? Do you want to write something like >>> > >>> > #if HAVE_INLINE_SSSE3 >>> > >>> > instead of >>> > >>> > #if HAVE_SSSE3 && HAVE_INLINE_ASM >>> > >>> > ? >>> >>> Right now, in practice: >>> >>> HAVE_SSSE3 means "we support inline ssse3" >>> HAVE_SSE2 means "we support inline sse2" >>> HAVE_AVX means "we support yasm avx" but depends on HAVE_SSSE3 >>> >>> I wonder whether it makes sense to have a "generic" HAVE_SSSE3 anyway >>> - when would we use it, what would it mean? I think in practice, we >>> probably want a HAVE_INLINE_SSSE3, as you said, because yes, there's >>> compilers that don't support this, but do support HAVE_INLINE_ASM in >>> general. Likewise, HAVE_AVX could be renamed HAVE_YASM_AVX or so. >>> Having HAVE_YASM_SSSE3 seems pointless, I don't think we support any >>> yasm/nasm version that doesn't understand ssse3, so it'd always be 1. >>> However, this would make it clear that HAVE_SSSE3 and HAVE_AVX don't >>> and shouldn't depend on each other. >> >> Try dropping the line >> >> avx_deps="ssse3" >> >> from configure and see if that works out the way you want it to. > > I'm still wondering if it makes sense to change the names to reflect > what they do, to prevent more misunderstandings. > > Plus, someone (i.e. me) needs to go over all our x86 simd function > pointer inits and make sure we use HAVE_INLINE_SSSE3 only for inline, > not yasm. Also, HAVE_SSE2, HAVE_SSE, HAVE_MMX2, HAVE_MMX need such > rules (are they inline? yasm? both?) and the same check in init > functions.
I hear no further opinions, so I suppose nobody minds if I replace HAVE_MMX2/SSE/SSSE3 with HAVE_INLINE_*, HAVE_AVX/FMA4 with HAVE_YASM_* and remove the dependency of avx on ssse3? I'll also go over the code and remove all uses of HAVE_MMX2/HAVE_SSSE3 around yasm code. Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
