[LLVMdev] PointerIntPair causing trouble

Stefanus Du Toit stefanus.dutoit at rapidmind.com
Fri May 1 06:09:03 PDT 2009


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 it sounds like the same issue. We'll let you know when we  
know more.

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

Just to be clear, PointerIntPair doesn't (AFAIK) store the integer in  
the "high bits" of the pointer. It just uses the "higher parts" of the  
"low available bits" of the pointer. So, if a pointer is always  
aligned such that it always has 4 bits clear on the low side, and you  
only need to store one bit, it'll be stored in bit 3 (counting from  
the LSB towards the MSB).

It may be that the alignment assumptions being made are simply wrong  
on Windows. So far we've been trying to track down whether this is  
actually the cause or if something's wrong with the Module coming into  
InstCombine, but given that you're seeing a similar problem elsewhere,  
it's not unlikely that this is the real cause.

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

--
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/82133c08/attachment.html>


More information about the llvm-dev mailing list