search for: celt_fir_permit_overflow

Hi, Attached are two patches. Patch 1 refactors silk_LPC_analysis_filter(). And Patch 2 optimizes the new function celt_fir_permit_overflow() for ARM NEON. Please recommend a better function name. We did the same internal code review and testing already. Thanks, Linfeng -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20170215/c44c8029/attachment-000...

...messy. It has 2 branches chosen by #ifdef SMALL_FOOTPRINT. For floating-point, the 2 branches are identical (except the operation sequence of accumulating x[i] to sum, which is not a big deal). For fixed-point, the 2 branches are different. I separate them into 2 functions: the new celt_fir(), and celt_fir_permit_overflow() which is the SMALL_FOOTPRINT branch. The only difference for fixed-point is: celt_fir(): the sum is truncated first and then accumulated to x[i] and saturated. celt_fir_permit_overflow(): x[i] is accumulated to the sum first and then truncated saturated. Maybe this is the reason why silk_LPC_ana...

...ring the #else case a bit (see below). > For floating-point, the 2 branches are identical (except the operation > sequence of accumulating x[i] to sum, which is not a big deal). > For fixed-point, the 2 branches are different. I separate them into 2 > functions: the new celt_fir(), and celt_fir_permit_overflow() which is > the SMALL_FOOTPRINT branch. > The only difference for fixed-point is: > celt_fir(): the sum is truncated first and then accumulated to x[i] and > saturated. > celt_fir_permit_overflow(): x[i] is accumulated to the sum first and > then truncated saturated. Actually, t...

...It seems to me like it's mostly duplicating the celt_fir() optimizations? Did I miss anything? Cheers, Jean-Marc On 15/02/17 02:22 PM, Linfeng Zhang wrote: > Hi, > > Attached are two patches. Patch 1 refactors silk_LPC_analysis_filter(). > And Patch 2 optimizes the new function celt_fir_permit_overflow() for > ARM NEON. > > Please recommend a better function name. > > We did the same internal code review and testing already. > > Thanks, > Linfeng > > > > _______________________________________________ > opus mailing list > opus at xiph.org > http...

Hi Linfeng, On 15/02/17 02:22 PM, Linfeng Zhang wrote: > Attached are two patches. Patch 1 refactors silk_LPC_analysis_filter(). > And Patch 2 optimizes the new function celt_fir_permit_overflow() for > ARM NEON. > > Please recommend a better function name. In most other cases, we've just added the _ovflw() suffix to functions/macros where signed overflow is allowed (suppressed using unsigned cast). > We did the same internal code review and testing already. Thanks, I...

...is > appropriate when we have --enable-assertions without --enable-check-asm, > wheras 1) is appropriate the rest of the time. That way we can test for > overflows in the CELT code, without preventing optimization of the SILK > code. > > > Because of silk_LPC_analysis_filter(), celt_fir_permit_overflow() must > > behave the same for both floating-point and fixed-point, and this is why > > we defined ADD32_FIXED(), ..., PSHR32_FIXED() etc. > > I don't think you will need these anymore, but if you ever need > fixed-point macros that remain integer for float compilation, the...

Linfeng Zhang wrote: > xcorr_kernel() itself is great and provides many gains. The only issue > is that calling it in a for loop makes it less efficient. Do you think it would be possible to improve the API of xcorr_kernel() so that calling it in a loop is more efficient? I haven't looked at an instruction-level profile, but I find it hard to believe that the function

Hi! I'm not deep i the code, but from my experience even older gcc (4.3.4) does function inlining at -O2, and at -O3 it inlines almost any function inside one module. Once I even let it inline across modules (-combine). I'm not talking about explicit inline functions; just about automatic optimization. So did you check that frequent function calls actually happen? I'm a bit afraid

Hi Timothy, Do you think it would be possible to improve the API of xcorr_kernel() so > that calling it in a loop is more efficient? > If it could be inlined, it will be more efficient. Besides memory bouncing, frequent function call is expensive. The other advantage to wiring up xcorr_kernel() is that it applies in more > places than your intrinsics-only celt_fir() implementation.