[LLVMdev] PointerIntPair causing trouble

[OvermindDL1]

On Mon, May 4, 2009 at 2:15 PM, OvermindDL1 <overminddl1 at gmail.com> wrote:
> On Mon, May 4, 2009 at 12:02 PM, Stefanus Du Toit
> <stefanus.dutoit at rapidmind.com> wrote:
>> /* snip PointerIntPair bug */
>
> I had made a toy language a month ago to catch back up to the latest
> svn LLVM api and for some reason anytime I used a compare operator (<,
> =, or > are all this toy language has) that was inside a function
> definition (a prime example is this code "(begin (define (fib n) (if
> (< n 3) 1 (+ (fib (- n 1)) (fib (- n 2))))) (fib (+ 1 3)))" of the toy
> language, even if reduced so all it does is return the (< n 3) part),
> then anytime I JITed the function and called it, when the JIT compiled
> it, it always crashed.  I ran out of time to mess with it due to RL
> issues, but I tried to debug that one section of code for 3 days
> straight, tried every combination I could think of and so forth.  When
> I debug into the JIT compiler and followed it, it always crashed when
> it got the Uses of the instruction that used the compare (which was
> always a zero-extend to 32-bit integer since every variable in this
> toy language is a 32-bit integer, but it also did it if I removed that
> instruction, changed it to something else, etc...) it went into the
> function, and ended up going through about 8 or so other functions
> that did not look like they did anything but route to other
> instructions (testing class type, removing references if necessary, so
> on and so forth, would not std::tr1::type_traits be *much* better for
> this stuff, just including Boost.Type_Traits would make it work on
> other platforms, and less code in your base to deal with), and the
> final instruction call returned a pointer to what should have been the
> compare, but it was always in some other random (non-allocated)
> memory.  Although I cannot check right now (still real-life issues in
> the way, I could check in two weeks, maybe sooner if I get a free
> moment while at home), but from what I remember of the pointer value,
> I would bet real money that the bit pattern got shifted from what the
> Compare instruction pointer value was supposed to be.
>
> Hence, I bet the issue I was seeing and tried to fix for a couple of
> days before I ran out of time is this exact issue, and yes, I am using
> Visual Studio 2005.  I have the toy language at my local home svn, if
> anyone wants access I can give you all the link so you can download
> and try it out (built with LLVM trunk SVN about a month or two ago,
> and Boost 1.40, hence, Boost trunk SVN) to confirm that this is the
> issue, or if you fix this issue in LLVM trunk, then I can resync and
> rebuild LLVM and see if that fixes the problem I have, the toy
> language code "(begin (define (tes n) (< n 1)))" reliably causes the
> bug I had been experiencing (as does the full Fibonacci function
> above).
>
> Actually, I am *very* curious if this is the bug.  I can try to see if
> it is now that I know what to look for (or if you fix it in SVN then I
> will first make sure the bug still exists in mine, when it does then I
> will update LLVM to the latest trunk and test again, if it was fixed
> that I will be giving many thanks), but the earliest that I might be
> able to check will be this coming Thursday night.
>

Also, it does not only happen with the JIT, but also some passes, for
example, if I add this pass:
m_FunctionPassManager->add(llvm::createPromoteMemoryToRegisterPass());
It happens inside that one as well, so it is not just a JIT occurrence.