On Mon, Jul 30, 2012 at 06:52:09AM -0700, Ronald S. Bultje wrote: > 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.
There are two capabilities that are interesting in this context: a) cpu b) compiler c) assembler Our current HAVE_FOO macros indicate a mix of everything. It seems to be the time to separate the capabilities. So first off, do we need all three capabilities separately or do we just need to separate compiler from assembler capabilities or ...? Diego _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
