search for: __lp64__

...h b/silk/macros.h index 2f24950..bc30303 100644 --- a/silk/macros.h +++ b/silk/macros.h @@ -43,17 +43,20 @@ POSSIBILITY OF SUCH DAMAGE. #define opus_unlikely(x) (!!(x)) #endif +/* Set this if opus_int64 is a native type of the CPU. */ +#define OPUS_FAST_INT64 (defined(__x86_64__) || defined(__LP64__) || defined(_WIN64)) + /* This is an OPUS_INLINE header file for general platform. */ /* (a32 * (opus_int32)((opus_int16)(b32))) >> 16 output have to be 32bit int */ -#if defined(__x86_64__) || defined(__LP64__) || defined(_WIN64) +#if OPUS_FAST_INT64 #define silk_SMULWB(a32, b32)...

Hello all, I get unresolved external symbol __muloti4 when attempting to compile GNU m4 for Windows commandline. See details in bug: https://bugs.llvm.org/show_bug.cgi?id=16404#c22 Looking into this, I see that some parts of compiler-rt are disabled for Windows due to the __LP64__ define. The code seem not portable 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, ming...

...384,14 @@ Builder.defineMacro("__amd64"); Builder.defineMacro("__x86_64"); Builder.defineMacro("__x86_64__"); + if (PointerWidth == 64 && getLongWidth() == 64) { + Builder.defineMacro("_LP64"); + Builder.defineMacro("__LP64__"); + } else if (PointerWidth == 32 && getLongWidth() == 32 && + getIntWidth() == 32) { + Builder.defineMacro("_ILP32"); + Builder.defineMacro("__ILP32__"); + } } else { DefineStd(Builder, "i386", Opts); }...

Hi, I'm working on bringing up complete coverage for a Gentoo x32 "desktop" system. I've been cooking up quite a few patches for various packages to push upstream, but right now, the biggest blocker is the lack of support for building with/codegen targeting x32 in llvm/clang. Since the x32 patches were sent last year, I see support code has landed in LLVM, and basic handling of

...384,14 @@ Builder.defineMacro("__amd64"); Builder.defineMacro("__x86_64"); Builder.defineMacro("__x86_64__"); + if (PointerWidth == 64 && getLongWidth() == 64) { + Builder.defineMacro("_LP64"); + Builder.defineMacro("__LP64__"); + } else if (PointerWidth == 32 && getLongWidth() == 32 && + getIntWidth() == 32) { + Builder.defineMacro("_ILP32"); + Builder.defineMacro("__ILP32__"); + } } else { DefineStd(Builder, "i386", Opts); }...

...>> -#if !defined(__x86_64__) && !defined(__ia64__) && !defined(__sparc_v9__) > >> +#if !defined(__x86_64__) && !defined(__ia64__) && !defined(__sparc_v9__) && \ > >> + !defined(__powerpc64__) > > > > Why not just !defined(__LP64__) ? > > _BITSIZE == 64 is really the right formula... if I remember correctly, there were some > 64-bit platforms (Alpha?) which didn't conform, though. I will look at this later today. > > -hpa indeed aboves line contains an mistake by an earlier patch of mine. -#if !defin...

...... *:Darwin:*:*) UNAME_PROCESSOR=`uname -p` || UNAME_PROCESSOR=unknown case $UNAME_PROCESSOR in i386) eval $set_cc_for_build if [ "$CC_FOR_BUILD" != 'no_compiler_found' ]; then if (echo '#ifdef __LP64__'; echo IS_64BIT_ARCH; echo '#endif') | \ (CCOPTS= $CC_FOR_BUILD -E - 2>/dev/null) | \ grep IS_64BIT_ARCH >/dev/null then UNAME_PROCESSOR="x86_64" fi fi ;...

...ne) #define UADD32(a,b) ((a)+(b)) #define USUB32(a,b) ((a)-(b)) +/* Set this if opus_int64 is a native type of the CPU. */ +/* Assume that all LP64 architectures have fast 64-bit types; also x86_64 (which can be ILP32 for x32) + and Win64 (which is LLP64). */ +#define OPUS_FAST_INT64 (defined(__LP64__) || defined(__x86_64__) || defined(_WIN64)) + #define PRINT_MIPS(file) #ifdef FIXED_POINT diff --git a/silk/macros.h b/silk/macros.h index bc30303..1ba614a 100644 --- a/silk/macros.h +++ b/silk/macros.h @@ -34,6 +34,7 @@ POSSIBILITY OF SUCH DAMAGE. #include "opus_types.h" #include...

...here's no reason to go through all that when a simple 64-bit multiply will do. The SILK macros in "macros.h" already make this distinction but you don't see it in your benchmarks because the OPUS_FAST_INT64 macro only looks for 64-bit x86, and doesn't check for ARM64. > No, __LP64__ is set on arm64, both on iOS and on Linux. (64-bit long and pointer.) This is included in the OPUS_FAST_INT64 test. > > The tests for __x86_64__ and for _WIN64 are in OPUS_FAST_INT64 because those are the two common platforms with fast native int64 types which *aren?t* LP64 ? x86_64 can be...

Hi Jonathan, I'm sorry to bring this up again, and I don't want to beat a dead horse, but I was very surprised by your benchmarks so I took a little closer look. I think what's happening is that it's a little unfair to compare the ARM64 inline assembly to the C code, because looking at the C macros in "fixed_generic.h" for MULT16_32_Q16 and MULT16_32_Q15 you find

Hi Jack, > The new dragonegg 2.9 sources fail to build against either FSF gcc 4.5.2 or 4.5.3svn > (with the i386_static.diff patch applied) on x86_64-apple-darwin10. In both cases, the > build fails as... what does the command ./TargetInfo -p return (the TargetInfo program is created during the dragonegg build). Some of your errors are consistent with this program failing to run.

...UNAME_PROCESSOR=`uname -p` || UNAME_PROCESSOR=unknown > case $UNAME_PROCESSOR in > i386) > eval $set_cc_for_build > if [ "$CC_FOR_BUILD" != 'no_compiler_found' ]; then > if (echo '#ifdef __LP64__'; echo IS_64BIT_ARCH; echo '#endif') | \ > (CCOPTS= $CC_FOR_BUILD -E - 2>/dev/null) | \ > grep IS_64BIT_ARCH >/dev/null > then > UNAME_PROCESSOR="x86_64" >...

...e, there's no reason to go through all that when a simple 64-bit multiply will do. The SILK macros in "macros.h" already make this distinction but you don't see it in your benchmarks because the OPUS_FAST_INT64 macro only looks for 64-bit x86, and doesn't check for ARM64. No, __LP64__ is set on arm64, both on iOS and on Linux. (64-bit long and pointer.) This is included in the OPUS_FAST_INT64 test. The tests for __x86_64__ and for _WIN64 are in OPUS_FAST_INT64 because those are the two common platforms with fast native int64 types which *aren?t* LP64 ? x86_64 can be x32, and...

--- configure.ac | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index f52d2c2..e1a6e9b 100644 --- a/configure.ac +++ b/configure.ac @@ -190,7 +190,7 @@ AC_ARG_ENABLE([rtcd], [enable_rtcd=yes]) AC_ARG_ENABLE([intrinsics], - [AS_HELP_STRING([--disable-intrinsics], [Disable intrinsics optimizations for ARM(float) X86(fixed)])],, +

..., there's no reason to go through all that when a simple 64-bit multiply will do. The SILK macros in "macros.h" already make this distinction but you don't see it in your benchmarks because the OPUS_FAST_INT64 macro only looks for 64-bit x86, and doesn't check for ARM64. No, __LP64__ is set on arm64, both on iOS and on Linux. (64-bit long and pointer.) This is included in the OPUS_FAST_INT64 test. The tests for __x86_64__ and for _WIN64 are in OPUS_FAST_INT64 because those are the two common platforms with fast native int64 types which *aren?t* LP64 ? x86_64 can be x32, and...

The new dragonegg 2.9 sources fail to build against either FSF gcc 4.5.2 or 4.5.3svn (with the i386_static.diff patch applied) on x86_64-apple-darwin10. In both cases, the build fails as... GCC=/sw/lib/gcc4.5/bin/gcc-4 LLVM_CONFIG=/sw/bin/llvm-config make CPPFLAGS="-DENABLE_LTO -I/sw/include" Compiling utils/TargetInfo.cpp <command-line>: warning: "__STDC_LIMIT_MACROS"

WARNING: This is not compatible with the previous lz4 patchset. If you''re using experimental compression that isn''t in mainline kernels, be prepared to backup and restore or decompress before upgrading, and have backups in case it eats data (which appears not to be a problem any more, but has been during development). These patches add lz4 and lz4hc compression

Linux 3.11 added respective support, so I think we should follow suit. 1: xen: add LZ4 decompression support 2: libxc: add LZ4 decompression support Signed-off-by: Jan Beulich <jbeulich@suse.com>

Hi, so here it is, LZ4 compression method inside btrfs. The patchset is based on top of current Chris'' for-linus + Andi''s snappy implementation + the fixes from Li Zefan. Passes xfstests and stresstests. I haven''t measured performance on wide range of hardware or workloads, rather wanted to publish the patches before I get distracted again. I''d like to ask

...(LZ4_uncompress_unknownOutputSize(s_start + 4, d_start, bufsiz, + d_len) < 0); +} + +/* + * CPU Feature Detection + */ + +/* 32 or 64 bits ? */ +#if (defined(__x86_64__) || defined(__x86_64) || defined(__amd64__) || \ + defined(__amd64) || defined(__ppc64__) || defined(_WIN64) || \ + defined(__LP64__) || defined(_LP64)) +#define LZ4_ARCH64 1 +#else +#define LZ4_ARCH64 0 +#endif + +/* + * Little Endian or Big Endian? + * Note: overwrite the below #define if you know your architecture endianess. + */ +#if (defined(__BIG_ENDIAN__) || defined(__BIG_ENDIAN) || \ + defined(_BIG_ENDIAN) || defined(_AR...