search for: _m_x64

_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-Luyssen wro...

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.org/pipermail...

...e 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/attachmen...

--- 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))

...le as is to the MS compiler, but according to my tests the code compiles and links OK with clang: I have not tested functionality though. Regarding the __LP64__ define, it's wrong to define it for Windows. SUA/Interix have LP64 long type model, while Cygwin, mingw and native Windows have LLP64. _M_X64 or __x86_64__ is more common. So I wonder, is the disabled compiler-rt parts intentional and not suitable for Windows? If not so, what can be done to enable it? Thanks Erik

...2, 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 > > Ca...

...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/20...

...educated guess is currently 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. Wo...

...dll" /i C:\Python-2.7.10\PCbuild\x64-temp-Release\kill_python\kill_python.tlog /r C:\PYTHON-2.7.10\PCBUILD\KILL_PYTHON.C /b MSBuildConsole_CancelEvent306536dcec844c0c97517539ced8ed5d /c C:\Python-2.7.10\PCbuild\CL.exe /c /I..\Include /I..\PC /Zi /nologo /W3 /WX- /O2 /Ob1 /Oi /GL /D _WIN64 /D _M_X64 /D NDEBUG /D _WIN32 /GF /Gm- /MT /GS /Gy /fp:precise /Zc:wchar_t /Zc:forScope /Fo"C:\Python-2.7.10\PCbuild\x64-temp-Release\kill_python\\" /Fd"C:\Python-2.7.10\PCbuild\x64-temp-Release\kill_python\vc120.pdb" /Gd /TC /errorReport:queue /USECL:MS_OPTERON /GS- kill_python.c TRACKER...

...he 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

.../* 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

...s in the specified arguments. If we can't run cpuid on the host, +/// return true. +bool GetX86CpuIDAndInfoEx(unsigned value, unsigned subleaf, unsigned *rEAX, + unsigned *rEBX, unsigned *rECX, unsigned *rEDX) { +#if defined(__x86_64__) || defined(_M_AMD64) || defined (_M_X64) + #if defined(__GNUC__) + // gcc doesn't know cpuid would clobber ebx/rbx. Preseve it manually. + asm ("movq\t%%rbx, %%rsi\n\t" + "cpuid\n\t" + "xchgq\t%%rbx, %%rsi\n\t" + : "=a" (*rEAX), + "=S" (*rEBX),...

I'm trying to compile some large programs with clang on Windows (with a view to compiling to bit code and then running some whole program optimisations on the bit code). Take for example the Python 2.7 interpreter: As is typically the case, the usual build procedure involves running msbuild which invokes the Microsoft compiler. The most obvious procedure would then be to substitute

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

.../* 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 ***********************************

...diff --git a/win32/config.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_...

...diff --git a/win32/config.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_...

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]