search for: _m_ix86

_WIN32, WIN32, WIN64, and _WIN64 are the wrong definitions to be gating this on in the first place. They aren't at all meant to be x86/x86-64 specific. At best, they're 32-bit/64-bit specific, but that's not the intended use in the code. The correct definitions are _M_IX86 and _M_X64, as Martin said. I sent a patch to this ML that fixed these a few months ago but it was forgotten/ignored. Hopefully the issue gets addressed this time. Cameron On Nov 6, 2014 9:53 AM, "Martin Storsj?" <martin at martin.st> wrote: > On Thu, 6 Nov 2014, Hugo Beauz?e-...

...nd _WIN64 are the wrong definitions to be gating > this > > on in the first place. They aren't at all meant to be x86/x86-64 > specific. > > At best, they're 32-bit/64-bit specific, but that's not the intended use > in > > the code. The correct definitions are _M_IX86 and _M_X64, as Martin said. > > > > I sent a patch to this ML that fixed these a few months ago but it was > > forgotten/ignored. Hopefully the issue gets addressed this time. > > This one, I gather? > > http://lists.xiph.org/pipermail/opus/attachments/20140406/e19d33c...

--- celt/float_cast.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/celt/float_cast.h b/celt/float_cast.h index ede6574..4892e2c 100644 --- a/celt/float_cast.h +++ b/celt/float_cast.h @@ -90,14 +90,14 @@ #include <math.h> #define float2int(x) lrint(x) -#elif (defined(_MSC_VER) && _MSC_VER >= 1400) && (defined (WIN64) || defined (_WIN64))

From the neighbouring list, http://lists.xiph.org/pipermail/opus/2014-April/002592.html "proper architecture-specific MSVC definitions, _M_IX86 and _M_X64" So this patch changes _WIN64 to _M_X64 (the corresponding code enables _BitScanReverse64) -------------- next part -------------- A non-text attachment was scrubbed... Name: bitmath.patch Type: application/octet-stream Size: 938 bytes Desc: not available Url : http://lists.xiph.or...

...: > _WIN32, WIN32, WIN64, and _WIN64 are the wrong definitions to be gating this > on in the first place. They aren't at all meant to be x86/x86-64 specific. > At best, they're 32-bit/64-bit specific, but that's not the intended use in > the code. The correct definitions are _M_IX86 and _M_X64, as Martin said. > > I sent a patch to this ML that fixed these a few months ago but it was > forgotten/ignored. Hopefully the issue gets addressed this time. This one, I gather? http://lists.xiph.org/pipermail/opus/attachments/20140406/e19d33cd/attachment.obj Best, Tristan &...

...definitions to be > gating this > > on in the first place. They aren't at all meant to be x86/x86-64 > specific. > > At best, they're 32-bit/64-bit specific, but that's not the > intended use in > > the code. The correct definitions are _M_IX86 and _M_X64, as > Martin said. > > > > I sent a patch to this ML that fixed these a few months ago but it was > > forgotten/ignored. Hopefully the issue gets addressed this time. > > This one, I gather? > http://lists.xiph.org/pipermail/opus/att...

...else typedef _w64 int ssize_t; #endif A discussion of "_w64" - http://msdn.microsoft.com/en-us/library/s04b5w00(VS.71).aspx. It's only supported on later versions of Visual Studio, so something like #if !defined(_W64) # if !defined(__midl) && (defined(_X86_) || defined(_M_IX86)) && _MSC_VER >= 1300 # define _W64 __w64 # else # define _W64 # endif #endif would be needed. Regards, Michael Smith -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100401/dc25bf4b/attachment.h...

...ing to use the MSVC x86 code path (with x86 assembly). This was because WIN32 and _WIN32 are defined in ARM projects for WP8 libraries (for source compatibility reasons I assume). I?ve attached a patch which changes WIN32/_WIN32 and WIN64/_WIN64 to the proper architecture-specific MSVC definitions, _M_IX86 and _M_X64. Thanks, Cameron -------------- next part -------------- A non-text attachment was scrubbed... Name: float_cast_archfix.diff Type: application/octet-stream Size: 769 bytes Desc: not available Url : http://lists.xiph.org/pipermail/opus/attachments/20140406/e19d33cd/attachment.obj

...gt; > > /* Win32 doesn't seem to have these functions. > -- > 2.1.1 As MSVC might support other architectures than arm and x86 (they did support mips, alpha and itanium at some points in time), I think it might be better to use this instead: ... && (defined(_M_IX86) || defined(_M_X64)) // Martin

...ntly that X86_64TargetMachine::getJITMatchQuality is the interesting point. I have noticed that all the points in the codebase that try to detect x86-64 are currently using the gcc-style "__x86_64__" preprocessor symbol. The Visual Studio compiler, instead, defines _M_X64 (similar to the _M_IX86 define that matches __x86__). Adding a defined(_M_X64) case to all the existing #ifdefs is no big deal, but I notice that two of them (one in X86JitInfo.cpp and one in X86Subtarget.cpp) are guarding inline assembly blocks written in the gcc-style inline assembly syntax. Would adding cases for the...

...subleaf); + *rEAX = registers[0]; + *rEBX = registers[1]; + *rECX = registers[2]; + *rEDX = registers[3]; + return false; + #else + return true; + #endif + #else + return true; + #endif +#elif defined(i386) || defined(__i386__) || defined(__x86__) || defined(_M_IX86) + #if defined(__GNUC__) + asm ("movl\t%%ebx, %%esi\n\t" + "cpuid\n\t" + "xchgl\t%%ebx, %%esi\n\t" + : "=a" (*rEAX), + "=S" (*rEBX), + "=c" (*rECX), + "=d" (*rEDX) +...

I agree with Tim, you need to implement a GetCpuIDAndInfoEx function in Host.cpp and pass the correct value to ecx. Also you need to verify that 7 is a valid leaf because an invalid leaf is defined to return the highest supported leaf on that processor. So if a processor supports say leaf 6 and not leaf 7, then an access leaf 7 will return the data from leaf 6 causing unrelated bits to be

Paolo Invernizzi wrote: > There was a similar problem some time ago, and was resolved with alloca. > I think it's a better solution to use the stack instead of the heap... I tend to agree, but the constructors won't get called if it's an object array -- anyway, this particular case there was no objects, just pointers and bools so alloca should be fine. I'll leave it to

...h> > > /* Win32 doesn't seem to have these functions. > -- > 2.1.1 As MSVC might support other architectures than arm and x86 (they did support mips, alpha and itanium at some points in time), I think it might be better to use this instead: ... && (defined(_M_IX86) || defined(_M_X64)) // Martin ------------------------------ _______________________________________________ opus mailing list opus at xiph.org http://lists.xiph.org/mailman/listinfo/opus End of opus Digest, Vol 70, Issue 3 ***********************************

...onfig.h b/win32/config.h index 46ff699..10fbf33 100644 --- a/win32/config.h +++ b/win32/config.h @@ -35,9 +35,28 @@ POSSIBILITY OF SUCH DAMAGE. #define OPUS_BUILD 1 -/* Enable SSE functions, if compiled with SSE/SSE2 (note that AMD64 implies SSE2) */ -#if defined(_M_X64) || (defined(_M_IX86_FP) && (_M_IX86_FP >= 1)) -#define __SSE__ 1 +#if defined(_M_IX86) || defined(_M_X64) +/* Can always build with SSE intrinsics (no special compiler flags necessary) */ +#define OPUS_X86_MAY_HAVE_SSE +#define OPUS_X86_MAY_HAVE_SSE2 +#define OPUS_X86_MAY_HAVE_SSE4_1 + +/* Pre...

...onfig.h b/win32/config.h index 46ff699..10fbf33 100644 --- a/win32/config.h +++ b/win32/config.h @@ -35,9 +35,28 @@ POSSIBILITY OF SUCH DAMAGE. #define OPUS_BUILD 1 -/* Enable SSE functions, if compiled with SSE/SSE2 (note that AMD64 implies SSE2) */ -#if defined(_M_X64) || (defined(_M_IX86_FP) && (_M_IX86_FP >= 1)) -#define __SSE__ 1 +#if defined(_M_IX86) || defined(_M_X64) +/* Can always build with SSE intrinsics (no special compiler flags necessary) */ +#define OPUS_X86_MAY_HAVE_SSE +#define OPUS_X86_MAY_HAVE_SSE2 +#define OPUS_X86_MAY_HAVE_SSE4_1 + +/* Pre...

The attached patch cleans up Opus's x86 intrinsics configury. It: * Makes ?enable-intrinsics work with clang and other non-GCC compilers * Enables RTCD for the floating-point-mode SSE code in Celt. * Disables use of RTCD in cases where the compiler targets an instruction set by default. * Enables the SSE4.1 Silk optimizations that apply to the common parts of Silk when Opus is built in

Hi All, Since I continue to base my work on top of Jonathan's patch, and my previous Ne10 fft/ifft/mdct_forward/backward patches, I thought it would be better to just post all new patches as a patch series. Please let me know if anyone disagrees with this approach. You can see wip branch of all latest patches at https://git.linaro.org/people/viswanath.puttagunta/opus.git Branch:

Hi Timothy, As I mentioned earlier [1], I now fixed compile issues with fixed point and resubmitting the patch. I also have new patch that does intrinsics optimizations for celt_pitch_xcorr targetting aarch64. You can find my latest work-in-progress branch at [2] For reference, you can use the Ne10 pre-built libraries at [3] Note that I am working with Phil at ARM to get my patch at [4]

Hi All, As per Timothy's suggestion, disabling mdct_forward for fixed point. Only effects armv7,armv8: Extend fixed fft NE10 optimizations to mdct Rest of patches are same as in [1] For reference, latest wip code for opus is at [2] Still working with NE10 team at ARM to get corner cases of mdct_forward. Will update with another patch when issue in NE10 gets fixed. Regards, Vish [1]: