[LLVMdev] PointerIntPair causing trouble

[Stefanus Du Toit]

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.

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




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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090501/a021811f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pointer_traits_workaround.diff
Type: application/octet-stream
Size: 979 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090501/a021811f/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090501/a021811f/attachment-0001.html>