search for: getsignedint

...xtension. 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 instructions in X86 as opposed to no-sign extension where only one ‘and’ with mask is needed for retrieving the int. From: David Blaikie [mailto:dblaikie at gmail.com] Sent: Wednesday, April 4, 2018 7:43 AM To: Riyaz Puthiyapurayil <Riyaz....

...interIntPair<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 instructions in X86 as opposed to > no-sign extension where only one ‘and’ with mask is needed for retrieving > the int. > > > > *From:* David Blaikie [mailto:dblaikie at gmail.com] > *Sent:* Wednesday, April 4, 2018...

...; >> 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 instructions in X86 as opposed to >> no-sign extension where only one ‘and’ with mask is needed for retrieving >> the int. >> >> >> >> *From:* David Blaikie [mailto:dblaikie at gmail.com] >> *...

...ointerIntPair<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 instructions in X86 as opposed to no-sign extension where only one ‘and’ with mask is needed for retrieving the int. > >   <> > From: David Blaikie [mailto:dblaikie at gmail.com <mailto:dblaikie at gmail.com>] > Sent:...

...xtension. 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 instructions in X86 as opposed to no-sign extension where only one ‘and’ with mask is needed for retrieving the int. From: David Blaikie [mailto:dblaikie at gmail.com<mailto:dblaikie at gmail.com>] Sent: Wednesday, April 4, 2018 7:43 AM...

I'd suggest someone try fixing this & see if it breaks anything that can't reasonably be fixed (before we go assuming this is by design/shouldn't be fixed just because it's the way it is today). On Wed, Apr 4, 2018 at 7:16 AM Riyaz Puthiyapurayil via llvm-dev < llvm-dev at lists.llvm.org> wrote: > It won't move the sign bit, so negative values won't fit,

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