similar to: PATCH: bugfixes for bitmath.h

lvqcl wrote: > More or less detailed explanation of this patch. I've applied part of that patch. > 1. The first parameter of _BitScanReverse() and _BitScanReverse64() is > a pointer to unsigned long (4-byte int). On windows, yes, unsigned long is 4 bytes for both 32 and 64 bit versions. This is not true for most Unices. > However _BitScanReverse64() is called with a pointer to

This patch adds support for other compilers and systems including MSVC, Intel C compiler etc.. --- src/libFLAC/bitmath.c | 48 ------------- src/libFLAC/bitreader.c | 54 ++------------- src/libFLAC/include/private/bitmath.h | 120 ++++++++++++++++++++++++++++++--- 3 files changed, 116 insertions(+), 106 deletions(-) diff --git a/src/libFLAC/bitmath.c

1) FLAC supports only MSVS 2005 and newer, so (_MSC_VER >= 1400) is always true and can be removed. 2) The argument for FLAC__clz_uint32() is of FLAC__uint32 type, so FLAC__clz_soft_uint32() should have the same argument type. 3) The patch removes unnecessary parentheses around 'word' variable. 4) It also replaces "sizeof(FLAC__uint32) * CHAR_BIT - 1 -

Found this code: ftp://ftp.samba.org/pub/unpacked/ntdb/lib/ccan/ilog/ilog.c Tests show that it's faster to use the following code in FLAC__bitmath_ilog2_wide(): static const unsigned char DEBRUIJN_IDX32[32]={ 0, 1,28, 2,29,14,24, 3,30,22,20,15,25,17, 4, 8, 31,27,13,23,21,19,16, 7,26,12,18, 6,11, 5,10, 9 }; FLAC__uint32 v; int m;

rutine -> routine Also MSVC complains that FLAC__uint32* (unsigned int*) is not of the same type as unsigned long* --- a\src\libFLAC\include\private\bitmath.h 2013-08-13 13:30:24.000000000 +0400 +++ b\src\libFLAC\include\private\bitmath.h 2013-08-14 10:20:51.484053700 +0400 @@ -78,12 +78,12 @@ return _bit_scan_reverse(v) ^ 31U; #elif defined(__GNUC__) && (__GNUC__ >= 4 ||

The following changes since commit b78d8e4db10e57b8d82bb82e4e3662d5dedd7255: FLAC__bitmath_ilog2,FLAC__bitmath_ilog2_wide,COUNT_ZERO_MSBS: add gcc specific optimizations (2012-03-28 15:43:48 -0300) are available in the git repository at: git://github.com/crrodriguez/flac.git master for you to fetch changes up to 3a060556772c5d6a6464afddfda7c3ad2f93a306: Remove winamp2 plugin.

FLAC__bitmath_ilog2_wide() function is still problematic: 1) it cannot be compiled with MSVS 2) it returns correct results only when compiles with GNUC 3) it mentions LGPL which isn't good for a BSD-licensed library Here's the patch that should fix these issues. (about LGPL -> CC0 change: http://lists.xiph.org/pipermail/flac-dev/2013-September/004356.html ) -------------- next part

--- src/libFLAC/include/private/bitmath.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/libFLAC/include/private/bitmath.h b/src/libFLAC/include/private/bitmath.h index 61b0e03..d32b1a7 100644 --- a/src/libFLAC/include/private/bitmath.h +++ b/src/libFLAC/include/private/bitmath.h @@ -42,7 +42,7 @@ #endif /* Will never be emitted for MSVC, GCC, Intel compilers */

Cristian Rodr?guez wrote: > The following changes since commit b78d8e4db10e57b8d82bb82e4e3662d5dedd7255: > > FLAC__bitmath_ilog2,FLAC__bitmath_ilog2_wide,COUNT_ZERO_MSBS: add gcc > specific optimizations (2012-03-28 15:43:48 -0300) > > are available in the git repository at: > > git://github.com/crrodriguez/flac.git master > > for you to fetch changes up

Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Well first of all, none of them apply :-). I'll try to redo the necessary patches with git. > * Remove restrict definition from include/share/compat.h. Applied. BTW, I tried to use 'restrict' keyword with MSVS 2010 and 2012 and in fact they don't support it. Only --restrict is supported. > * libFLAC and

Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Patch applied, tested, commited and pushed. Great. But, what about my other patches? I admit that many of them aren't necessary, but (imho) a couple of them are important. I can explain in detail why I think this.

In the precompute_partition_info_sums_ function, instead of selecting 64-bit accumulator when the signal bps is larger than 16, revert to the original approach based on partition size, but make room for few extra bits to not overflow with unusual signals where the average residual magnitude may be larger than bps. It slightly improves the performance with standard encoding levels and 16-bit files

The commit http://git.xiph.org/?p=flac.git;a=commitdiff;h=0a0a10f358345f749e4a05021301461994f1ffc5 (from 31 Mar 2007) adds the following conditional: if(FLAC__bitmath_ilog2(default_partition_samples) + bps < 32) And the commit http://git.xiph.org/?p=flac.git;a=commitdiff;h=f081524c19eeafd08f4db6ee5d52a9634c60f475 has this: if(FLAC__bitmath_ilog2(default_partition_samples) +

--- src/libFLAC/include/private/bitmath.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/libFLAC/include/private/bitmath.h b/src/libFLAC/include/private/bitmath.h index 42ce639..e5c7695 100644 --- a/src/libFLAC/include/private/bitmath.h +++ b/src/libFLAC/include/private/bitmath.h @@ -74,7 +74,7 @@ static inline unsigned int FLAC__clz_uint32(FLAC__uint32 v) { /* Never

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

On Thu, Jun 19, 2014 at 03:30:22PM +0400, lvqcl wrote: > BTW, what can you say about the following place in stream_decoder.c > in read_subframe_lpc_() function: > > /*@@@@@@ technically not pessimistic enough, should be more like > if( (FLAC__uint64)order * ((((FLAC__uint64)1)<<bps)-1) * ((1<<subframe->qlp_coeff_precision)-1) < (((FLAC__uint64)-1)

I don't understand the comment in src/libFLAC/stream_decoder.c: /*@@@@@@ technically not pessimistic enough, should be more like if( (FLAC__uint64)order * ((((FLAC__uint64)1)<<bps)-1) * ((1<<subframe->qlp_coeff_precision)-1) < (((FLAC__uint64)-1) << 32) ) */ if(bps + subframe->qlp_coeff_precision + FLAC__bitmath_ilog2(order) <= 32) see

On Thu, Jun 19, 2014 at 06:25:57PM +0400, lvqcl wrote: > Now I wonder why evaluate_lpc_subframe_() function in stream_encoder.c contains > almost the same code, but without any comments that it's not enough pessimistic: > evaluate_lpc_subframe_(): > > if(subframe_bps + qlp_coeff_precision + FLAC__bitmath_ilog2(order) <= 32) > if(subframe_bps <= 16 &&

On Thu, 2008-10-23 at 11:17 -0700, Evan Cheng wrote: > > On Oct 22, 2008, at 11:09 AM, Sanjiv.Gupta at microchip.com wrote: > > > In our case, storeRegToStackSlot, loadRegFromStackSlot clobbers some > > other physical register which may be holding a live value used > > somewhere else. How do I make regalloc aware so that it saves the > > value before

Hi all, Some non trivial legalization of operations which aren't supported by the backend would benefit from having the optimizer pass on them. I noticed some example trying to optimize various pieces of code over the past weeks. One offender is the cttz/ctlz intrinsic when defined on 0. On X86, BSR and NSF are undefined on 0, and only recent CPU have the LZCNT and TZCNT instructions that