search for: __optimize__

...x86 - 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 I did specify the release build with cmake; the lack of crashing on exit of programs compiled therewith confirms that :-) As far as I can see, the reason for the incorrect reporting is in CommandLine.cpp: #ifndef __OPTIMIZE__ cout << "DEBUG build"; #else cout << "Optimized build"; #endif According to a Google search, gcc sets __OPTIMIZE__ when -O2 or better is used, so presumably that's the intent of the above and the reason it doesn't work with Visual C++. I'...

...ling without optimization, if so opus will be very slow. [-W#pragma-messages] # pragma message "You appear to be compiling without optimization, if so opus will be very slow." Looking at the lines in question I see: #if defined(__GNUC__) && (__GNUC__ >= 2) && !defined(__OPTIMIZE__) && !defined(OPUS_WILL_BE_SLOW) # pragma message "You appear to be compiling without optimization, if so opus will be very slow." #endif A quick find/grep, however, shows no place where __OPTIMIZE__ or OPUS_WILL_BE_SLOW are actually defined--so presumably I would have to pass the...

...and above > x86-64 - 64-bit X86: EM64T and AMD64 > > I did specify the release build with cmake; the lack of crashing on > exit of programs compiled therewith confirms that :-) As far as I can > see, the reason for the incorrect reporting is in CommandLine.cpp: > > #ifndef __OPTIMIZE__ > cout << "DEBUG build"; > #else > cout << "Optimized build"; > #endif > > According to a Google search, gcc sets __OPTIMIZE__ when -O2 or better > is used, so presumably that's the intent of the above and the reason > it d...

SSIA Martin Kletzander (2): Don't redefine _FORTIFY_SOURCE Get rid of gnulib error bootstrap | 2 +- configure.ac | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) -- 1.8.3.2

...red Targets: > arm - ARM > cpp - C++ backend > thumb - Thumb > x86 - 32-bit X86: Pentium-Pro and above > x86-64 - 64-bit X86: EM64T and AMD64 > xcore - XCore > > Why I get DEBUG builds? It has been since r29020. :D depends on definition of __OPTIMIZE__ . Your llc.exe should be built with Release, if llc is bin/Release/llc.exe . I won't find corresponding predefinitions in cl.exe. http://msdn.microsoft.com/en-us/library/b0084kay(v=vs.100).aspx Shall we suppress the line "DEBUG build." under cl.exe ? ...Takumi

...6 @@ AC_SUBST([NO_UM_CFLAGS]) AC_DEFINE([lint], [1], [Define to 1 if the compiler is checking for lint.]) AC_DEFINE([GNULIB_PORTCHECK], [1], [Enable some gnulib portability checks.]) -AH_VERBATIM([FORTIFY_SOURCE],[ -/* Enable compile-time and run-time bounds-checking, and some warnings. */ -#if __OPTIMIZE__ && (! defined (_FORTIFY_SOURCE) || _FORTIFY_SOURCE < 2) -# undef _FORTIFY_SOURCE -# define _FORTIFY_SOURCE 2 -#endif]) AC_C_PROTOTYPES test "x$U" != "x" && AC_MSG_ERROR([Compiler not ANSI compliant]) -- 2.13.2

...Comments From laforge@netfilter.org 2003-04-19 13:57 ------- This bug is well known for about two years. However, we never thought that anybody was going to use it without optimization. I am currently unable to state if your fix is correct. The Issue is that we explicitly inserted those #ifndef __OPTIMIZE__ sections to make it work when no optimization is used. It was somehow related to gcc not accepting inline function declarations, if optimization was turned off. Rusty: Do you remember what the exact reason for those sections was? ------- You are receiving this mail because: ------- You are on...

...invoking the function implementing the intrinsic). + However, it is smart enough to eliminate the extra MOVD instruction. + For _mm_cvtepi16_epi32, it does the right thing, though does *not* optimize out + the extra MOVQ if it's specified explicitly */ + # if defined(__clang__) || !defined(__OPTIMIZE__) # define OP_CVTEPI8_EPI32_M32(x) \ (_mm_cvtepi8_epi32(_mm_cvtsi32_si128(*(int *)(x)))) - -# define OP_CVTEPI16_EPI32_M64(x) \ - (_mm_cvtepi16_epi32(_mm_loadl_epi64((__m128i *)(x)))) # else # define OP_CVTEPI8_EPI32_M32(x) \ (_mm_cvtepi8_epi32(*(__m128i *)(x))) +#endif +# if !defined(__...

...invoking the function implementing the intrinsic). + However, it is smart enough to eliminate the extra MOVD instruction. + For _mm_cvtepi16_epi32, it does the right thing, though does *not* optimize out + the extra MOVQ if it's specified explicitly */ + # if defined(__clang__) || !defined(__OPTIMIZE__) # define OP_CVTEPI8_EPI32_M32(x) \ (_mm_cvtepi8_epi32(_mm_cvtsi32_si128(*(int *)(x)))) - -# define OP_CVTEPI16_EPI32_M64(x) \ - (_mm_cvtepi16_epi32(_mm_loadl_epi64((__m128i *)(x)))) # else # define OP_CVTEPI8_EPI32_M32(x) \ (_mm_cvtepi8_epi32(*(__m128i *)(x))) +#endif +# if !defined(__...

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]:

Hi All, Changes from RFC v2 [1] armv7,armv8: Extend fixed fft NE10 optimizations to mdct - Overflow issue fixed by Phil at ARM. Ne10 wip at [2]. Should be upstream soon. - So, re-enabled using fixed fft for mdct_forward which was disabled in RFCv2 armv7,armv8: Optimize fixed point fft using NE10 library - Thanks to Jonathan Lennox, fixed some build fixes on iOS and some copy-paste errors Rest

Hello Timothy / Jean-Marc / opus-dev, This patch series is follow up on work I posted on [1]. In addition to what was posted on [1], this patch series mainly integrates Fixed point FFT implementations in NE10 library into opus. You can view my opus wip code at [2]. Note that while I found some issues both with the NE10 library(fixed fft) and with Linaro toolchain (armv8 intrinsics), the work

Two (not related to each other) refactorings: Patches 1-12 split configure.ac into smaller files using the m4_include mechanism. Patches 13-15 split out parts of guestfs.pod (ie. guestfs(3)) into three new manual pages: guestfs-hacking(3) - how to extend and contribute to libguestfs guestfs-internals(3) - architecture and internals guestfs-security(3) - security and CVEs Patch 16 is a