Closed GoogleCodeExporter closed 9 years ago
so far unable to repro. /arch: supports SSE, SSE2, AVX, AVX2 but not SSSE3.
With Intel C there are SSSE3 options.
Original comment by fbarch...@google.com
on 20 Aug 2014 at 5:58
I do a nightly with libvpx+libyuv with everything enabled under msvs, msys and
cygwin, but I don't have anything doing a reduced set there.
I have seen this problem with older gcc compilers though and there was a report
of an issue like this on openbsd.
Original comment by jz...@chromium.org
on 20 Aug 2014 at 6:34
inline assembly with gcc (and visual c) on intel cpus does not require special
compile flags.
e.g. you can compile avx2 code while building with -msse2
But intrinsics headers care. libyuv only uses a couple intrinsics.
cpuid and row_win
cpuid is for xgetbv which shouldnt care about flags.
row_win is ifdefed with MSCVER
#if defined (_M_X64)
#include <emmintrin.h>
#include <tmmintrin.h> // For _mm_maddubs_epi16
#endif
and
// This module is for Visual C.
#if !defined(LIBYUV_DISABLE_X86) && defined(_MSC_VER)
I'm guessing its a compiler variation like mingw or clang.
mingw sets _M_X64
clang-cl and icl set _MSC_VER
Original comment by fbarch...@google.com
on 20 Aug 2014 at 6:55
I had something for libvpx pendning with mingw actually:
https://gerrit.chromium.org/gerrit/#/c/71228/
I might be able to drop it after this.
Original comment by jz...@chromium.org
on 20 Aug 2014 at 7:31
row_win header conditionally included in r1058.
scale_win has an issue?
Original comment by fbarch...@google.com
on 21 Aug 2014 at 10:46
row_win was the problem at r1041, I should update the libvpx snapshot again.
I'll let you know after that.
Original comment by jz...@chromium.org
on 21 Aug 2014 at 11:24
Looks better on the libvpx side after grabbing r1060.
Original comment by jz...@chromium.org
on 22 Aug 2014 at 7:21
Thanks. Closing bug.
As followup there is a related issue with ios under some build systems.
xcode wants a single project for simulator and native builds with the same list
of source files. Currently we have a set of files that are neon specific.
We'll need them to be buildable, which I think they are, and to not have
gcc/clang options that would break other compilers/cpus.
Original comment by fbarch...@google.com
on 22 Aug 2014 at 9:53
Original issue reported on code.google.com by
fbarch...@google.com
on 19 Aug 2014 at 1:02