[LLVMdev] PointerIntPair causing trouble

[Gordon Henriksen]

On 2009-05-01, at 18:40, 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 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 simply by dropping this down to 2  
> bits, which gets us past our problem on Windows. I would appreciate  
> if you could verify that this works for you as well.
>
> To actually solve this properly I see two main options:
>
> (1) we could specialize PointerLikeTypeTraits for User*, and leave  
> the default value of NumLowBitsAvailable at 3.
> (2) we could drop the default NumLowBitsAvailable to 2 (or even use  
> _alignof and similar compiler-specific extensions to determine it),  
> and allow classes that assert that they are only ever allocated  
> through malloc to relax it back up to 3.
>

Something like this device should suffice; no need for extensions.

template<typename T>
class alignment_of {
   struct test {
     char a;
     T b;
   };

public:
   enum { value = sizeof(test) - sizeof(T) };
};

// usage: alignment_of<int>::value

TR1's type_traits header is now available on many platforms now, too.

> My preference would be for option (2), due to the difficulty of  
> tracking this bug down, and the risk of future similar bugs  
> happening. However, I'd appreciate some feedback from the LLVM  
> developer community on this. Please let me know what you think, and  
> I'll be happy to prepare a patch.
>
> I'm still wondering why this wasn't an issue on other platforms. One  
> possibility is that Use is being bumped up to 16 bytes in size, and  
> thus Users never get placed at less than an 8-byte boundary.  
> However, in that case, the whole point of the "use diet"  
> optimization is lost! I'll investigate and try to find out.
>
> I'm also still not sure why the assertion in  
> PointerIntPair::setPointer() did not get triggered by the  
> User::allocHungOffUses() implementation in Use.cpp. Perhaps the  
> assertion is wrong (it looks reasonable, though) or perhaps there is  
> something else going on I haven't seen yet. I'll look into this some  
> more as well.
>
> Let me know if the workaround works for you, and I'd appreciate  
> feedback from anyone (Chris? Gabor?) as to how best to proceed.
>
> Thanks!
>
> Stefanus
>
>
> <pointer_traits_workaround.diff>
>
> On 1-May-09, at 6:32 AM, Nicolas Capens wrote:
>
>> 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 pointer to begin with, but surely  
>> the lower bits must be a safer location than the upper bits?
>>
>> The actual crash I’m seeing is preceded by an assert in  
>> X86InstrInfo::sizeOfImm: "Immediate size not set!". Tracing  
>> backward, I’m seeing a MachineInstr with opcode MOV32rm and  
>> NumOperands equal to 6 (which is 5 in earlier revisions). I’m not  
>> sure if this actually helps explain the bug but it’s one of the  
>> weird things that happen with revision 67979 and subsequent  
>> revisions…
>>
>> All help appreciated.
>>
>> Nicolas
>> <ATT00001.txt>
>
> --
> Stefanus Du Toit <stefanus.dutoit at rapidmind.com>
>   RapidMind Inc.
>   phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090501/c0b03dee/attachment.html>