<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 2009-05-01, at 18:40, Stefanus Du Toit wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Nicolas,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>To actually solve this properly I see two main options:</div><div><br></div><div>(1) we could specialize PointerLikeTypeTraits for User*, and leave the default value of NumLowBitsAvailable at 3.</div><div>(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.</div><div><br></div></div></blockquote><div><br></div><div>Something like this device should suffice; no need for extensions.</div><div><br></div><div>template<typename T></div><div>class alignment_of {</div><div> struct test {</div><div> char a;</div><div> T b;</div><div> };</div><div> </div><div>public:</div><div> enum { value = sizeof(test) - sizeof(T) };</div><div>};</div><div><br></div><div>// usage: alignment_of<int>::value</div><div><br></div><div>TR1's type_traits header is now available on many platforms now, too.</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Let me know if the workaround works for you, and I'd appreciate feedback from anyone (Chris? Gabor?) as to how best to proceed.</div><div><br></div><div>Thanks!</div><div><br></div><div>Stefanus</div><div><br></div><div><br></div><div></div><span><pointer_traits_workaround.diff></span></div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div></div><div><br><div><div>On 1-May-09, at 6:32 AM, Nicolas Capens wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="color: rgb(0, 0, 0); "><div lang="EN-US" link="blue" vlink="purple"><div class="Section1"><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">Hi all,<o:p></o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">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.<o:p></o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">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?<o:p></o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">The actual crash I’m seeing is preceded by an assert in<span class="Apple-converted-space"> </span><span style="font-size: 10pt; font-family: 'Courier New'; ">X86InstrInfo::sizeOfImm</span>:<span class="Apple-converted-space"> </span><span style="font-size: 10pt; font-family: 'Courier New'; color: rgb(163, 21, 21); ">"Immediate size not set!"</span>. 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…<o:p></o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">All help appreciated.<o:p></o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">Nicolas<span style="font-size: 10pt; font-family: 'Courier New'; color: rgb(163, 21, 21); "><o:p></o:p></span></div><span><ATT00001.txt></span></div></div></span></blockquote></div><br><div apple-content-edited="true"> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>--</div><div>Stefanus Du Toit <<a href="mailto:stefanus.dutoit@rapidmind.com">stefanus.dutoit@rapidmind.com</a>></div><div> RapidMind Inc.</div><div> phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463</div><div><br class="khtml-block-placeholder"></div></div></div></div></div></span><br class="Apple-interchange-newline"> </div><br></div></div>_______________________________________________<br>LLVM Developers mailing list<br>LLVMdev@cs.uiuc.edu <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></blockquote></div><br></body></html>