search for: lsbits

...lock(FLAC__BitWriter *bw, const FL msbits = uval >> parameter; #if 0 /* OPT: can remove this special case if it doesn't make up for the extra compare (doesn't make a statistically significant difference with msvc or gcc/x86) */ - if(bw->bits && bw->bits + msbits + lsbits <= FLAC__BITS_PER_WORD) { /* i.e. if the whole thing fits in the current bwword */ - /* ^^^ if bw->bits is 0 then we may have filled the buffer and have no free bwword to work in */ + if(bw->bits && bw->bits + msbits + lsbits <= FLAC__BITS_PER_WORD) { /* i.e. if the whole...

Hello everyone At EuroLLVM I presented some testing work we have been doing on improving correctness of the MC Layer for ARM. There seemed to be interest from the community in seeing the results of this test suite. Background ----------- We are using a test suite, called MC Hammer, that compares MC with an ARM in-house implementation of the same functionality. The test space for this suite is

...h emit between 1 and O(10) SDValues, depending on alignment information), and then runs DAGCombine. To lower an i16 STORE that is known to be in the high-addressed 2 bytes of a word on my little-endian target, I emit and LD4 from the word-aligned address and an SRL 16 to shift the i16 into the LSbits of the register. DAGCombine visit()s an ISD::SRL node and notices that it is right-shifting the result of an LD4 from %arrayidx4 by 16 bits, and replaces it with an LD2 from %arrayidx+2. Replaces -------- 0x17f7070: i32,ch = load 0x17faa00, 0x17f7f70, 0x17f6a70<LD4[%arrayidx4]> 0x17f94c0:...

...pointer to an array from the User object and there may be a variable number of them. Layout a) will be modelled by prepending the User object by the Use[] array. ...---.---.---.---.-------... | 0 | 0 | 2 | 1 | User ```---`---`---`---`-------``` 12 12 12 12 a bit-encoding in the 2 LSBits of the Use::Val will allow to find the start of the User object: 00 --> binary digit 0 01 --> binary digit 1 10 --> stop and calc (s) 11 --> full stop (S) Given a Use*, all we have to do is walk till we get a stop and we either have a User immediately behind or we have to walk to the...

Hi All, I work on a backend for a target similar to Mips, where large immediates are loaded into registers with 2 instructions, 1 to load the MSBits and 1 to load the LSBits. I've noticed a recurring pattern where, despite low register pressure, these constants will be rematerialized in every iteration of a loop, rather than being hoisted. Here's an example using the mips-unknown-unknown target and Clang/LLVM HEAD. From newlib's implementation of str...

...and O(10) SDValues, > depending on alignment information), and then runs DAGCombine.  To lower > an i16 STORE that is known to be in the high-addressed 2 bytes of a word > on my little-endian target, I emit and LD4 from the word-aligned address > and an SRL 16 to shift the i16 into the LSbits of the register. > > DAGCombine visit()s an ISD::SRL node and notices that it is > right-shifting the result of an LD4 from %arrayidx4 by 16 bits, and > replaces it with an LD2 from %arrayidx+2. > > Replaces > -------- > 0x17f7070: i32,ch = load 0x17faa00, 0x17f7f70, 0x17f6a...

...ues, >> depending on alignment information), and then runs DAGCombine. To lower >> an i16 STORE that is known to be in the high-addressed 2 bytes of a word >> on my little-endian target, I emit and LD4 from the word-aligned address >> and an SRL 16 to shift the i16 into the LSbits of the register. >> >> DAGCombine visit()s an ISD::SRL node and notices that it is >> right-shifting the result of an LD4 from %arrayidx4 by 16 bits, and >> replaces it with an LD2 from %arrayidx+2. >> >> Replaces >> -------- >> 0x17f7070: i32,ch = lo...

...ode for a target like ARM or X86 as a comparison. Evan On Mar 7, 2012, at 10:38 AM, Matt Johnson wrote: > Hi All, > I work on a backend for a target similar to Mips, where large > immediates are loaded into registers with 2 instructions, 1 to load the > MSBits and 1 to load the LSBits. I've noticed a recurring pattern > where, despite low register pressure, these constants will be > rematerialized in every iteration of a loop, rather than being hoisted. > Here's an example using the mips-unknown-unknown target and Clang/LLVM > HEAD. From newlib's i...

...; depending on alignment information), and then runs DAGCombine.  To lower >>> an i16 STORE that is known to be in the high-addressed 2 bytes of a word >>> on my little-endian target, I emit and LD4 from the word-aligned address >>> and an SRL 16 to shift the i16 into the LSbits of the register. >>> >>> DAGCombine visit()s an ISD::SRL node and notices that it is >>> right-shifting the result of an LD4 from %arrayidx4 by 16 bits, and >>> replaces it with an LD2 from %arrayidx+2. >>> >>> Replaces >>> -------- &gt...

...comparison. > > Evan > > On Mar 7, 2012, at 10:38 AM, Matt Johnson wrote: > >> Hi All, >> I work on a backend for a target similar to Mips, where large >> immediates are loaded into registers with 2 instructions, 1 to load the >> MSBits and 1 to load the LSBits. I've noticed a recurring pattern >> where, despite low register pressure, these constants will be >> rematerialized in every iteration of a loop, rather than being hoisted. >> Here's an example using the mips-unknown-unknown target and Clang/LLVM >> HEAD. From new...

On 3 Mai, 18:56, Stefanus Du Toit <stefanus.dut... at rapidmind.com> wrote: > On 1-May-09, at 8:35 PM, Chris Lattner wrote: > > > I still don't understand why this is a problem, but I decreased the > > default to 2 bits.  Please verify that this helps, > > I think I've figured out what's going on, and why no assertions are   > caused by this. It

..._WORD_ALL_ONES is not 32-bit, so better to replace it with the proper 32-bit constant. 5) In FLAC__bitwriter_write_rice_signed_block() the new variable total_bits was added (just as in FLAC__bitwriter_write_rice_signed()). The code was simplified. Example: - bw->bits = bw->bits + msbits + lsbits; + bw->bits += total_bits; -------------- next part -------------- A non-text attachment was scrubbed... Name: 3_bitwriter.patch Type: application/octet-stream Size: 4007 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20151228/5fab8c38/attachment.obj

Hi, The Speex reference refers to the Vorbis comment format to define the comment header: http://www.xiph.org/ogg/vorbis/doc/v-comment.html However, speexenc violates that format in a couple of ways: 1. it doesn't append a "framing bit" to the end of the comments packet. According to the Vorbis comment spec, an ERROR must be flagged when decoding such a

Hi Gabor, On 3-May-09, at 4:57 PM, Gabor Greif wrote: > Your analysis is perfectly correct. I Was AFK for the last two days, > so I couldn't > tell you this same story. Thanks, glad I was on the right track :). > The algorithm relies on the fact that the LSBit of the first "pointer" > in User > is zero. This is normally the case with VPtrs, which are

On 1-May-09, at 8:35 PM, Chris Lattner wrote: > I still don't understand why this is a problem, but I decreased the > default to 2 bits. Please verify that this helps, I think I've figured out what's going on, and why no assertions are caused by this. It doesn't necessarily have anything to do with User* pointer alignment per se (although I believe that could still

On May 1, 2009, at 3:40 PM, Stefanus Du Toit wrote: > Hi Nicolas, > > Looks like Preston and I have found the cause of the problem. The > issue is with PointerLikeTypeTraits<T*>::NumLowBitsAvailable. This > is set to 3, which basically assumes that unless the traits are > specialized for a particular pointer type, objects of that type are > allocated with