Hi, On Mon, Jul 30, 2012 at 2:41 AM, Måns Rullgård <[email protected]> wrote: > "Ronald S. Bultje" <[email protected]> writes: >> 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'm not at all convinced this is what we really want. Instead of trying > to change one part of the mess to match another part at random, we > should figure out what semantics we really want from these options, then > change everything to match that. It may be a little more effort, but it > will be worth it.
Maybe somebody should open a RFC thread to figure out what it is that we want - oh wait. So in other words, can you be more forthcoming about what it is that we want? I've given my opinion here a few times now. A RFC cannot be a one-way street. Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
