search for: pointerintpair

llvm::PointerIntPair<double*, 3, signed> P; P.setInt(-4); Ideally, the value range for a 3-bit signed integer should be [-4,3]. But the above call to setInt will fail. Essentially, the signed int field in PointerIntPair is behaving the same as an 3-bit unsigned field which has the legal value range of [0,7]....

On 4 Apr 2018, at 11:01, Florian Hahn via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > On 04/04/2018 05:34, Riyaz Puthiyapurayil via llvm-dev wrote: >> llvm::PointerIntPair<double*, 3, signed> P; >> P.setInt(-4); >> Ideally, the value range for a 3-bit signed integer should be [-4,3]. But the above call to setInt will fail. Essentially, the signed int field in PointerIntPair is behaving the same as an 3-bit unsigned field which has the legal value ra...

I do agree that sign-extension is the right thing to do. Unlike bit-fields, llvm::PointerIntPair has asserts checking that the int value is within range. So if you assign an out of range value, it should fail with an assertion: llvm::PointerIntPair<SomeType*, 3, int> pip; pip.setInt(7); // can be made to fail as the valid range // of signed 3-bit values is [-4:3] The abo...

Hi Nicolas, On 1-May-09, at 6:32 AM, Nicolas Capens wrote: > I’ve located a regression that causes my project to crash. It’s in > revision 67979, where PointerIntPair is changed from storing the > integer in the upper bits instead of the lower bits. My project is > an experimental JIT-compiler in Windows. We're looking into a similar bug right now. We see the problem elsewhere (early on in optimization, during the first instcombine pass) but i...

Rather than “fixing” it, it might be better to support a separate method for signed extension. My reasoning is as follows: int x = 7; llvm::PointerIntPair<double*, 3, int> pip; pip.setInt(x); There could be code out there that expects pip.getInt() to return 7 and not -1. So if you really want to set a negative and return a negative value, a separate method setSignedInt and getSignedInt may be OK. Further, sign-extension would need two shift i...

It won't move the sign bit, so negative values won't fit, unless you have a 3 bit signed type ;) Note that if you assign negative values to and then read from a signed bit-field, you would do sign extension. So 3-bit signed types do exist in C++. It begs the question why PointerIntPair supports signed int types if it always loses the sign. Is it just to avoid signed/unsigned comparison when comparing the return value of getInt with signed types? Or to use enums that default to a signed type? In any case, this should be clearly documented if there is no intention to fix it. / Riy...

On 04/04/2018 11:15, David Chisnall wrote: > On 4 Apr 2018, at 11:01, Florian Hahn via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> >> On 04/04/2018 05:34, Riyaz Puthiyapurayil via llvm-dev wrote: >>> llvm::PointerIntPair<double*, 3, signed> P; >>> P.setInt(-4); >>> Ideally, the value range for a 3-bit signed integer should be [-4,3]. But the above call to setInt will fail. Essentially, the signed int field in PointerIntPair is behaving the same as an 3-bit unsigned field which has the legal...

Hi, On 04/04/2018 05:34, Riyaz Puthiyapurayil via llvm-dev wrote: > llvm::PointerIntPair<double*, 3, signed> P; > > P.setInt(-4); > > Ideally, the value range for a 3-bit signed integer should be [-4,3]. > But the above call to setInt will fail. Essentially, the signed int > field in PointerIntPair is behaving the same as an 3-bit unsigned field > which...

I'd argue that bitfield sign extensions are surprising and are usually a source of bugs. It would be much more explicit and less error prone for the user to write the sign extension if they want it. By extension, it seems good that PointerIntPair doesn't do sign extension when the type happens to be signed. On Wed, Apr 4, 2018 at 9:47 AM David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I think it'd be reasonable to model this on the same behavior as int to > short to int round-tripping & not to spe...

...e sign bit, so negative values won't fit, unless you have > a 3 bit signed type ;) > > > Note that if you assign negative values to and then read from a signed > bit-field, you would do sign extension. So 3-bit signed types do exist in > C++. > > It begs the question why PointerIntPair supports signed int types if it > always loses the sign. Is it just to avoid signed/unsigned comparison when > comparing the return value of getInt with signed types? Or to use enums > that default to a signed type? In any case, this should be clearly > documented if there is no intenti...

...orting both. On Wed, Apr 4, 2018 at 9:27 AM Riyaz Puthiyapurayil < Riyaz.Puthiyapurayil at synopsys.com> wrote: > Rather than “fixing” it, it might be better to support a separate method > for signed extension. My reasoning is as follows: > > > > int x = 7; > > llvm::PointerIntPair<double*, 3, int> pip; > > pip.setInt(x); > > > > There could be code out there that expects pip.getInt() to return 7 and > not -1. > > > > So if you really want to set a negative and return a negative value, a > separate method setSignedInt and getSignedInt...

...<llvm-dev at lists.llvm.org> wrote: > > I'd argue that bitfield sign extensions are surprising and are usually a source of bugs. It would be much more explicit and less error prone for the user to write the sign extension if they want it. > > By extension, it seems good that PointerIntPair doesn't do sign extension when the type happens to be signed. > > On Wed, Apr 4, 2018 at 9:47 AM David Blaikie via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > I think it'd be reasonable to model this on the same behavior as int to...

Hi all, I've located a regression that causes my project to crash. It's in revision 67979, where PointerIntPair is changed from storing the integer in the upper bits instead of the lower bits. My project is an experimental JIT-compiler in Windows. So I was wondering if anyone had any clue why the new PointerIntPair implementation might fail. It doesn't seem very safe to me to store other data into a...

...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 malloc() and aligned to 8 bytes. While PointerLikeTypeTraits is overloaded for Use*, it is not overloaded for User*. lib/VMCore/Use.cpp uses a PointerIntPair<User*, 1, Tag>, and things go bad. Users are typically allocated in an array after a bunch of Uses, which are 12 bytes in size, so they may actually only be aligned to 4 bytes. The attached patch (which I don't intend to commit, it's just a workaround) works around this simpl...

...assumes that unless the traits are > specialized for a particular pointer type, objects of that type are > allocated with malloc() and aligned to 8 bytes. > > While PointerLikeTypeTraits is overloaded for Use*, it is not > overloaded for User*. lib/VMCore/Use.cpp uses a > PointerIntPair<User*, 1, Tag>, and things go bad. Users are > typically allocated in an array after a bunch of Uses, which are 12 > bytes in size, so they may actually only be aligned to 4 bytes. > > The attached patch (which I don't intend to commit, it's just a > workaround) w...

...ck :). > 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 could switch back without a loss. > > Btw. the alignment of pointers in a 32 bit machine is 4, so I do not > understand > how the traits define 3 free bits for them. Maybe sabre can explain > that chang...

..., std::allocator<short unsigned int> >*, std::__debug::vector<unsigned int, std::allocator<unsigned int> >*, std::__debug::vector<long unsigned int, std::allocator<long unsigned int> >*>::NumLowBitsAvailable’: /home/jayfoad2/git/llvm-project/llvm/include/llvm/ADT/PointerIntPair.h:144:48: required from ‘struct llvm::PointerIntPairInfo<void*, 2, llvm::pointer_union_detail::PointerUnionUIntTraits<std::__debug::vector<unsigned char, std::allocator<unsigned char> >*, std::__debug::vector<short unsigned int, std::allocator<short unsigned int> >*,...

...nt> >*, >> std::__debug::vector<unsigned int, std::allocator<unsigned int> >*, >> std::__debug::vector<long unsigned int, std::allocator<long unsigned >> int> >*>::NumLowBitsAvailable’: >> /home/jayfoad2/git/llvm-project/llvm/include/llvm/ADT/PointerIntPair.h:144:48: >> required from ‘struct llvm::PointerIntPairInfo<void*, 2, >> llvm::pointer_union_detail::PointerUnionUIntTraits<std::__debug::vector<unsigned >> char, std::allocator<unsigned char> >*, std::__debug::vector<short >> unsigned int, std::alloca...

...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 could switch back without a loss. Btw. the alignment of pointers in a 32 bit machine is 4, so I do not understand how the traits define 3 free bits for them. Maybe sabre can explain that change which caused the breakage. Is t...

...:__debug::vector<unsigned int, std::allocator<unsigned int> >*, >> >> std::__debug::vector<long unsigned int, std::allocator<long unsigned >> >> int> >*>::NumLowBitsAvailable’: >> >> /home/jayfoad2/git/llvm-project/llvm/include/llvm/ADT/PointerIntPair.h:144:48: >> >> required from ‘struct llvm::PointerIntPairInfo<void*, 2, >> >> llvm::pointer_union_detail::PointerUnionUIntTraits<std::__debug::vector<unsigned >> >> char, std::allocator<unsigned char> >*, std::__debug::vector<short >&gt...