"Ronald S. Bultje" <[email protected]> writes:

> From: "Ronald S. Bultje" <[email protected]>
>
> ---
>  configure            |    9 +++++++++
>  libavutil/internal.h |    6 +++++-
>  2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 351d8a0..4fc20a2 100755
> --- a/configure
> +++ b/configure
> @@ -1118,7 +1118,9 @@ HAVE_LIST="
>      MapViewOfFile
>      memalign
>      mkstemp
> +    mm_empty
>      mmap
> +    mmintrin_h
>      nanosleep
>      netinet_sctp_h
>      poll_h
> @@ -2646,6 +2648,13 @@ check_cc <<EOF && enable inline_asm
>  void foo(void) { __asm__ volatile ("" ::); }
>  EOF
>
> +if check_header mmintrin.h; then
> +    check_cc <<EOF && enable mm_empty
> +#include <mmintrin.h>
> +int main (void) { _mm_empty(); return 0; }
> +EOF
> +fi

The previous patch used intrin.h, now it's mmintrin.h.  Please explain.
Looking around my hard drive, most x86 compilers seem to have a
compatible mmintrin.h, so I guess this is better.

>  _restrict=
>  for restrict_keyword in restrict __restrict__ __restrict; do
>      check_cc <<EOF && _restrict=$restrict_keyword && break
> diff --git a/libavutil/internal.h b/libavutil/internal.h
> index 41e8a9a..81426af 100644
> --- a/libavutil/internal.h
> +++ b/libavutil/internal.h
> @@ -231,7 +231,7 @@ struct AVDictionary {
>  #   define ONLY_IF_THREADS_ENABLED(x) NULL
>  #endif
>
> -#if HAVE_MMX
> +#if HAVE_MMX && HAVE_INLINE_ASM
>  /**
>   * Empty mmx state.
>   * this must be called between any dsp function and float/double code.
> @@ -241,6 +241,10 @@ static av_always_inline void emms_c(void)
>  {
>      __asm__ volatile ("emms" ::: "memory");
>  }
> +#elif HAVE_MMX && HAVE_MM_EMPTY
> +#include <mmintrin.h>
> +
> +#define emms_c _mm_empty
>  #else /* HAVE_MMX */
>  #define emms_c()
>  #endif /* HAVE_MMX */
> -- 

This is still almost impossible to read.  Something like this would be
clearer:

#elif HAVE_MMX && HAVE_MM_EMPTY
#   include <mmintrin.h>
#   define emms_c() _mm_empty()
#else

-- 
Måns Rullgård
[email protected]
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to