search for: mozeiko

> Inline the init function: store 11 at the address of the "value" variable, > call printf with the string from r5. This is a bug, should have stored at an > offset of four (str r1, [r4,4]). Exactly! The IR is correct, the bug seems to be lower down. I'm no expert in the ARM back-end, though. But your report is detailed enough to help whoever is. ;) cheers, --renato

Thanks for confirming this. Is there anybody with experience with ARM JIT codegen who can take a look into this? Or can somebody direct where to look how JIT on ARM processes getelementptr instruction? -- Martins Mozeiko On Feb 17, 2010, at 19:14 , Renato Golin wrote: >> Inline the init function: store 11 at the address of the "value" variable, >> call printf with the string from r5. This is a bug, should have stored at an >> offset of four (str r1, [r4,4]). > > Exactly! The IR...

Hi. Sorry for bringing this again. I really need to find source of this bug. Can somebody give address/name of person who knows ARM implementation in LLVM in more details and to whom I could address my questions directly? -- Martins Mozeiko On Feb 19, 2010, at 19:43 , Martins Mozeiko wrote: > Thanks for confirming this. > > Is there anybody with experience with ARM JIT codegen who can take a look into this? > Or can somebody direct where to look how JIT on ARM processes getelementptr instruction? > > -- > M...

...nstant, i32 0, i32 0, i32 3), align 1 ret void } I don't see any problems with it. When I compile same bitcode file with llc.exe -march=arm, and use generated assembler file on my ARM, then code runs fine. What else could I check in this situation to determine more about problem? -- Martins Mozeiko

...nce to `_lexer_line' build/gengtype-yacc.o:/cygdrive/r/android/llvm/llvm-gcc4.2-objects/ gcc/../../llvm-gcc4.2-2.4.source/gcc/gengtype-yacc.y:165: more undefined references to `_lexer_line' follow collect2: ld returned 1 exit status make[2]: *** [build/gengtype.exe] Error 1 -- Martins Mozeiko

...tion. I don't know how well the canadian cross compile stuff works in 2.5. We made some improvements in that area for 2.6. If you have trouble with it, I'd suggest trying 2.6 (or even better, ToT svn) and seeing if things are improved there. -Jim On Sep 25, 2009, at 2:04 AM, Martins Mozeiko wrote: > Hello. > > My goal is to use LLVM with JIT compiler for ARM on Android device. > > Currently I have successfully built and executed LLVM bitcode with > interpreter on Android. Speed is not so great, that is why I want to > use JIT. > I tried building bitcode on win...

...p, #4] 0x40029074: ldr r11, [sp, #8] 0x40029078: ldr lr, [sp, #12] 0x4002907c: add sp, sp, #16 ; 0x10 0x40029080: bx lr And at the end restore registers from the stack and return. Can somebody confirm that this is a bug? Or am I missing something else here? -- Martins Mozeiko On Feb 17, 2010, at 12:23 , Renato Golin wrote: > On 15 February 2010 14:49, Martins Mozeiko <49640f8a at gmail.com> wrote: >> #include <stdio.h> >> struct Global { >> typedef unsigned char ArrayType[4]; >> ArrayType value; >> Global(const ArrayTyp...

On 15 February 2010 14:49, Martins Mozeiko <49640f8a at gmail.com> wrote: > #include <stdio.h> > struct Global { >  typedef unsigned char ArrayType[4]; >  ArrayType value; >  Global(const ArrayType& arg) { >    for (int i = 0; i < 4; i++) this->value[i] = arg[i]; >  } > }; > static const unsi...

...0xe3a0001e JIT: 0x4512e014: BX_RET 14, %reg0, %R0<imp-use,kill> 0xe12fff1e JIT: Finished CodeGen of [0x4512e010] Function: main: 8 bytes of text, 0 relocations JIT: Binary code: JIT: 00000000: e3a0001e e12fff1e *** I appreciate any suggestions what can I do in my situation. -- Martins Mozeiko

Hi. Sorry for reposting my mail, but can somebody at lest give some general ideas for what to look to solve my problem? -- Martins Mozeiko Begin forwarded message: > From: Martins Mozeiko <49640f8a at gmail.com> > Date: September 25, 2009 12:04:04 GMT+03:00 > To: llvmdev at cs.uiuc.edu > Subject: JIT on ARM > > Hello. > > My goal is to use LLVM with JIT compiler for ARM on Android device. > > Cur...

Hello > Sorry for bringing this again. > I really need to find source of this bug.  Can somebody give address/name of person who knows ARM implementation in LLVM in more details and to whom I could address my questions directly? Have you at least tried ARM JIT on svn head? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University