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.
On 4-May-09, at 4:15 PM, OvermindDL1 wrote:> 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.If it is the same problem (and it very much sounds like it is), it should be fixed in trunk now. Chris reduced the alignment assumption on pointers to 2 a few days ago. Sorry if that wasn't clear from the thread. The discussion since then has mostly been about whether we can improve on this, or if the status quo is OK. Stefanus -- Stefanus Du Toit <stefanus.dutoit at rapidmind.com> RapidMind Inc. phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463
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.
On Mon, May 4, 2009 at 2:33 PM, Stefanus Du Toit <stefanus.dutoit at rapidmind.com> wrote:> On 4-May-09, at 4:15 PM, OvermindDL1 wrote: >> 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. > > If it is the same problem (and it very much sounds like it is), it > should be fixed in trunk now. Chris reduced the alignment assumption > on pointers to 2 a few days ago. Sorry if that wasn't clear from the > thread. The discussion since then has mostly been about whether we can > improve on this, or if the status quo is OK.Wonderful then, I will give it a try at my next available opportunity (probably this coming Thursday night, unless I decide to shirk a duty or two...).