search for: lsbit

...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...

...able. The first example fails with an abort when they are turned on, and otherwise creates the instruction BFI r0, r0, #32, #-32. The second example does not abort and decodes to BFI r0, r0, #1, #2 (0xe7c20090). The ARMARM could be clearer on this point, but the real UAL should be BFI r0, r0, #lsbit #(msbit+1-lsbit) or BFI r0, r0, #3, #-2 In my opinion, the root cause of the problem is that BFI MCInsts store the mask as a 32-bit operand and converts to and from the msbit and lsbit fields during encode, decode, assemble and disassemble. I think it should store the msbit and lsbit fields as op...

...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 st...

...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, 0x17f6...

...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 = l...

...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...

...; 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 >>> -------- &g...

...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 ne...

...tagged pointer there, just some "random"   > data corresponding to the first sizeof(User*) bits of a User instance. Hi Stefanus! Your analysis is perfectly correct. I Was AFK for the last two days, so I couldn't tell you this same story. 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 "normally" placed there by ABIs. Originally, I just checked that bit verbatim, and later by means of PointerIntPair. The problem arose when PointerIntPair's layout changed. I think we cou...

..._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 "normally" > placed there > by ABIs. Originally, I just checked that bit verbatim, and later by > means of > PointerIntPair. The problem arose when PointerIntPair's...

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