search for: sum0

...im of the GVN pass. I have been reading a bit about global value numbering, and from what I understand, there are polynomial time algorithms for removing duplicate computations from loops[1]. I have an example program[2] which computes the sum of an array twice, in two separate accumulators. Here, sum0 and sum1 are both sums of the array A. void b01_sums(int size, int* A) { int sum0 = 0; int sum1 = 0; for (int i = 0; i != size; ++i) { sum0 = sum0 + A[i]; sum1 = sum1 + A[i]; printf("sum0: %d\nsum1: %d\n", sum0, sum1); } } I would have expected global value numberi...

The following series adds initial vector support for PowerPC64. On POWER9, flac --best is about 3.3x faster. Amitay Isaacs (2): Add m4 macro to check for C __attribute__ features Check if compiler supports target attribute on ppc64 Anton Blanchard (5): configure.ac: Remove SPE detection code configure.ac: Add VSX enable/disable configure.ac: Fix FLAC__CPU_PPC on little endian, and add

...and, there are polynomial time algorithms for removing > > duplicate computations from loops[1]. > > Yes > The current GVN will not do it. > > I have an example program[2] which computes the sum of an array > > twice, in two separate accumulators. > > > Here, sum0 and sum1 are both sums of the array A. > > > void b01_sums(int size, int* A) > > > { > > > int sum0 = 0; > > > int sum1 = 0; > > > for (int i = 0; i != size; ++i) > > > { > > > sum0 = sum0 + A[i]; > > > sum1 = sum1 +...

Constant propagation: %sum = add <N x float> %a, %b @llvm.reduce(ext <N x double> %sum) if %a and %b are vector of constants, the %sum also becomes a vector of constants. At this point you have @llvm.reduce(ext <N x double> %sum) and don't know what kind of reduction do you need. - Elena -----Original Message----- From: Renato Golin [mailto:renato.golin at linaro.org]

...l16 * y, opus_val32 sum[ 4 ], int len) + +void dual_inner_prod_sse(const opus_val16 *x, const opus_val16 *y01, const opus_val16 *y02, + int N, opus_val32 *xy1, opus_val32 *xy2) { - int j; - - __m128i vecX, vecX0, vecX1, vecX2, vecX3; - __m128i vecY0, vecY1, vecY2, vecY3; - __m128i sum0, sum1, sum2, sum3, vecSum; - __m128i initSum; - - celt_assert(len >= 3); - - sum0 = _mm_setzero_si128(); - sum1 = _mm_setzero_si128(); - sum2 = _mm_setzero_si128(); - sum3 = _mm_setzero_si128(); - - for (j=0;j<(len-7);j+=8) - { - vecX = _mm_loadu_si128((__m128i...

...l16 * y, opus_val32 sum[ 4 ], int len) + +void dual_inner_prod_sse(const opus_val16 *x, const opus_val16 *y01, const opus_val16 *y02, + int N, opus_val32 *xy1, opus_val32 *xy2) { - int j; - - __m128i vecX, vecX0, vecX1, vecX2, vecX3; - __m128i vecY0, vecY1, vecY2, vecY3; - __m128i sum0, sum1, sum2, sum3, vecSum; - __m128i initSum; - - celt_assert(len >= 3); - - sum0 = _mm_setzero_si128(); - sum1 = _mm_setzero_si128(); - sum2 = _mm_setzero_si128(); - sum3 = _mm_setzero_si128(); - - for (j=0;j<(len-7);j+=8) - { - vecX = _mm_loadu_si128((__m128i...

> That's possible. In any case, u-law conversion can be done with far less > than 1 MHz... About Speex, you would likely need to enable ARM > optimizations and set the complexity to 1 (default it 2). done with arm optimizations and i was still getting high load ... guess it's from gstreamer somewhere. I'll check that next week. thanks, - Christophe

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

On Fri, 7 Feb 2014, Timothy B. Terriberry wrote: > Martin Storsjo wrote: >> This is required in order to build using the built-in assembler >> in clang. > > These patches break the gcc build (with "Error: bad instruction"). Ah, right, sorry about that. > Documentation I've seen is contradictory on which order ({cond}{size} or > {size}{cond}) is correct.

...bit before the shift. I can fix this by accumulating each term into a long, but if the code scales the x[],y[] vectors to avoid this problem I could use parallel 16x16 multiply/adds. You can see this problem with the following test case. for (i=0;i<40;i++) { x[i]=-16384; y[i]=-32768; } sum0=inner_prod(x, y, 40); fprintf(stderr,"inner_prod0(%8d).\n",sum0); Jerry J. Trantow Applied Signal Processing, Inc. jtrantow@ieee.org

...r8, [r5], #2 + SUBSGE r12, r12, #1 + LDRHGT r8, [r5], #2 BGT celt_pitch_xcorr_edsp_process1u_loop1 ; Restore _x SUB r4, r4, r3, LSL #1 @@ -474,7 +474,7 @@ celt_pitch_xcorr_edsp_process2_1 ADDS r12, r12, #1 ; Stall SMLABB r10, r6, r8, r10 ; sum0 = MAC16_16(sum0, x_0, y_0) - LDRGTH r7, [r4], #2 + LDRHGT r7, [r4], #2 SMLABT r11, r6, r8, r11 ; sum1 = MAC16_16(sum1, x_0, y_1) BLE celt_pitch_xcorr_edsp_process2_done LDRH r9, [r5], #2 @@ -527,8 +527,8 @@ celt_pitch_xcorr_edsp_process1a_loop_done SUBGE...

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]

...I could use parallel 16x16 > multiply/adds. What do you mean here? > You can see this problem with the following test case. > > for (i=0;i<40;i++) > { > x[i]=-16384; > y[i]=-32768; > } The value -32768 is not supposed to happen in vectors sent to inner_prod. > sum0=inner_prod(x, y, 40); > fprintf(stderr,"inner_prod0(%8d).\n",sum0); Jean-Marc

...r12, r12, #1 - LDRGTH r8, [r5], #2 + LDRHGT r8, [r5], #2 BGT celt_pitch_xcorr_edsp_process1u_loop1 ; Restore _x SUB r4, r4, r3, LSL #1 @@ -474,7 +474,7 @@ celt_pitch_xcorr_edsp_process2_1 ADDS r12, r12, #1 ; Stall SMLABB r10, r6, r8, r10 ; sum0 = MAC16_16(sum0, x_0, y_0) - LDRGTH r7, [r4], #2 + LDRHGT r7, [r4], #2 SMLABT r11, r6, r8, r11 ; sum1 = MAC16_16(sum1, x_0, y_1) BLE celt_pitch_xcorr_edsp_process2_done LDRH r9, [r5], #2 @@ -527,8 +527,8 @@ celt_pitch_xcorr_edsp_process1a_loop_done SUBGE...

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

...nrow(X))) results.LRSM <- LRSM(X, mpoints = 1, groupvec = rGrps, se = TRUE) 2. I don't know how to make a design matrix myself. I tried making one with 1's along the diagonal, but it doesn't seem to work. I get an error: Error in likLR(X, W, mpoints, groupvec, model, st.err = se, sum0, etaStart) : Mismatch between number of rows (beta's) in W and number of items (categories) in X! This is from these commands: rGrps = c(rep.int(1, nrow(X))) W = matrix(data=NA, nrow=ncol(X), ncol=ncol(X)) for(i in 1:(ncol(X) - 8)) { vec = c(rep(0, i - 1),1,rep(0, (ncol(X) - i))) W[i,...

...(uint64_t *a, uint64_t *p, uint64_t *q, unsigned n) { uint64_t s = 0; while (n--) s += *p++ * *q++; *a = s; } which produces this IR after the MI builder has expanded GEPs: (I am borrowing LLVM IR syntax to describe the MI IR.) define void @dot(i32 %a, i32 %p, i32 %q, i32 %n) { entry: %sum0:i64,VecBank = const i64 0 %cmp1 = icmp eq i32 %n, 0 br i1 %cmp1, label %exit, label %loop loop: %iv:i32,IntBank = phi i32 [ %iv2, %loop ], [ %n, %entry ] %p1:i32,IntBank = phi i32 [ %p2, %loop ], [ %p, %entry ] %q1:i32,IntBank = phi i32 [ %q2, %loop ], [ %q, %entry ] %sum1:i64,VecBank...