search for: mtlr

...st(int X) { > int i; > for (i = 0; i < 1000; ++i) > Array[i] += X; > } > > Compile with -O3 on OS/X gave me this: > > _test: > mflr r5 > bcl 20,31,"L00000000001$pb" > "L00000000001$pb": > mflr r2 > mtlr r5 > addis r4,r2,ha16(L_Array$non_lazy_ptr-"L00000000001$pb") > li r2,0 > lwz r9,lo16(L_Array$non_lazy_ptr-"L00000000001$pb")(r4) > li r4,1000 > mtctr r4 > L9: > lwzx r7,r2,r9 ; load > add r...

...enerated for main functions is the following: .L.main: # BB#0: mflr 0 std 0, 16(1) stdu 1, -112(1) lis 3, .LCPI1_0 at ha li 4, 1 lfs 1, .LCPI1_0 at l(3) li 3, 0 bl foo nop addi 1, 1, 112 ld 0, 16(1) mtlr 0 blr Which is correct, however for the JIT one generated in memory the relocations generate some issues. First the 'lis 3, .LCPI1_0 at ha' can possible overflow which will generate an wrong relocation. Since the const data will be place just before the function code in JIT gener...

...mflr 0 > std 0, 16(1) > stdu 1, -112(1) > lis 3, .LCPI1_0 at ha > li 4, 1 > lfs 1, .LCPI1_0 at l(3) > li 3, 0 > bl foo > nop > addi 1, 1, 112 > ld 0, 16(1) > mtlr 0 > blr > > Which is correct, however for the JIT one generated in memory the relocations generate some issues. > > First the 'lis 3, .LCPI1_0 at ha' can possible overflow which will generate an wrong relocation. > Since the const data will be place just before th...

...sing -O3). :) >From hello.s: main: mflr 0 stw 31, -4(1) stw 0, 4(1) stwu 1, -16(1) lis 3, .Lstr at ha mr 31, 1 la 3, .Lstr at l(3) bl puts li 3, 0 addi 1, 1, 16 lwz 0, 4(1) lwz 31, -4(1) mtlr 0 blr By the strict letter of the 32-bit ABI, the save and restore of r31 at a negative offset of r1 is verboten. The ABI states the the stack space below the stack pointer is declared as volatile. I actually debugged a similar problem way back in my Blue Gene/L days, where gcc had a bug...

...0,8(%r3) + std %r31,8(%r3) + li %r3,0 /* indicate success */ + blr /* return */ .size .setjmp,.-.setjmp .section ".opd","aw" @@ -35,12 +54,32 @@ longjmp: .globl longjmp .globl .longjmp .longjmp: - lmw %r9,0(%r3) /* save r9..r31 */ - mtlr %r11 /* restore LR */ - mtcr %r12 /* restore CR */ - mr %r2,%r9 /* restore GPR2 (not needed) */ - mr %r1,%r10 /* restore stack */ - mr %r3,%r4 /* get return value */...

On Tue, 4 May 2004, Patrick Flanagan wrote: > I was able to run through all the C/C++ benchmarks in SPEC using LLVM. > I'm on OS X 10.3.3. I did a quick comparison between LLVM (latest from > CVS as of 4/27) and gcc 3.3 (Apple's build 20030304). For simplicity's > sake, the only flag I used was -O3 for each compiler and I was using > the C backend to generate native

I was able to run through all the C/C++ benchmarks in SPEC using LLVM. I'm on OS X 10.3.3. I did a quick comparison between LLVM (latest from CVS as of 4/27) and gcc 3.3 (Apple's build 20030304). For simplicity's sake, the only flag I used was -O3 for each compiler and I was using the C backend to generate native code for PPC. Most of the LLVM results were close to gcc

The latest binutils (2.21.2) assembler for the PPC64 complains about the .size directive emitted by LLVM as not containing an absolute expression. An example: __umodsi3: .quad .L.__umodsi3,.TOC. at tocbase .previous .L.__umodsi3: mflr 0 [snip] mtlr 0 blr .Ltmp0: .size __umodsi3, .Ltmp0-__umodsi3 The correct size expression should be .Ltmp0-.L.__umodsi3 The code which does this is in AsmPrinter.cpp: // If the target wants a .size directive for the size of the function, emit // it. if (MAI->hasDotTypeDotSizeDirecti...

On Tue, 2012-05-01 at 17:47 -0500, Hal Finkel wrote: > By default it should build for > whatever the current host is (no special flags required). To > specifically build for something else, use: > -ccc-host-triple powerpc64-unknown-linux-gnu > or > -ccc-host-triple powerpc-unknown-linux-gnu So LLVM isn't biarch capable? Meaning one LLVM compiler cannot generate both

...I took this very simple C function: int Array[1000]; void test(int X) { int i; for (i = 0; i < 1000; ++i) Array[i] += X; } Compile with -O3 on OS/X gave me this: _test: mflr r5 bcl 20,31,"L00000000001$pb" "L00000000001$pb": mflr r2 mtlr r5 addis r4,r2,ha16(L_Array$non_lazy_ptr-"L00000000001$pb") li r2,0 lwz r9,lo16(L_Array$non_lazy_ptr-"L00000000001$pb")(r4) li r4,1000 mtctr r4 L9: lwzx r7,r2,r9 ; load add r6,r7,r3 ; add stwx r6,...

.../* return */ + + .size .setjmp,.-.setjmp + .section ".opd","aw" +longjmp: + .quad .longjmp,.TOC.@tocbase,0 + .previous + .size longjmp,24 + .type .longjmp,@function + .globl longjmp + .globl .longjmp +.longjmp: + lmw %r9,0(%r3) /* save r9..r31 */ + mtlr %r11 /* restore LR */ + mtcr %r12 /* restore CR */ + mr %r2,%r9 /* restore GPR2 (not needed) */ + mr %r1,%r10 /* restore stack */ + mr %r3,%r4 /* get return value */...

...gt; stw 31, -4(1) > stw 0, 4(1) > stwu 1, -16(1) > lis 3, .Lstr at ha > mr 31, 1 > la 3, .Lstr at l(3) > bl puts > li 3, 0 > addi 1, 1, 16 > lwz 0, 4(1) > lwz 31, -4(1) > mtlr 0 > blr > > By the strict letter of the 32-bit ABI, the save and restore of > r31 at a negative offset of r1 is verboten. The ABI states the > the stack space below the stack pointer is declared as volatile. > I actually debugged a similar problem way back in my Blue Ge...

On Tue, 01 May 2012 17:23:07 -0500 Peter Bergner <bergner at vnet.ibm.com> wrote: > On Tue, 2012-05-01 at 16:06 -0500, Hal Finkel wrote: > > LLVM/clang now will build in the normal way (./configure; make > > install) on PPC (you'll need at least the 3.1 release candidate (or > > trunk)). I generally build on my PPC64 hosts with: > > make ENABLE_OPTIMIZED=1

.../* save r9..r31 */ + li %r3,0 /* indicate success */ + blr /* return */ + + .size setjmp,.-setjmp + + .type longjmp, at function + .globl longjmp +longjmp: + lmw %r9,0(%r3) /* save r9..r31 */ + mtlr %r11 /* restore LR */ + mtcr %r12 /* restore CR */ + mr %r2,%r9 /* restore GPR2 (not needed) */ + mr %r1,%r10 /* restore stack */ + mr %r3,%r4 /* get return value */...

On Jan 9, 2009, at 11:37 AMPST, Evan Cheng wrote: > This looks like a bar in ARMInstrInfo.td: > > BX_RET should be marked with Uses = [LR] since it uses LR. However, > this won't work if there is a call BL before the BX_RET. BL is marked > as if it implicitly define LR. So we'll end up with this (hello world > example): PPC has the call (BL) marked with Defs=LR and the

...r15,8(%r3) + ldu %r16,8(%r3) + ldu %r17,8(%r3) + ldu %r18,8(%r3) + ldu %r19,8(%r3) + ldu %r20,8(%r3) + ldu %r21,8(%r3) + ldu %r22,8(%r3) + ldu %r23,8(%r3) + ldu %r24,8(%r3) + ldu %r25,8(%r3) + ldu %r26,8(%r3) + ldu %r27,8(%r3) + ldu %r28,8(%r3) + ldu %r29,8(%r3) + ldu %r30,8(%r3) + ld %r31,8(%r3) + mtlr %r11 /* restore LR */ + mtcr %r12 /* restore CR */ + mr %r3,%r4 /* get return value */ + blr /* return */ + + .size .longjmp,.-.longjmp diff --git a/usr/klibc/arch/ppc64/syscall.c b/usr/klibc/arch/ppc64/syscall.c new file mode 100644 index 0000000..a5895fe --- /dev/null +++ b/usr/klibc/arc...

...gt; stdu 1, -112(1) > > lis 3, .LCPI1_0 at ha > > li 4, 1 > > lfs 1, .LCPI1_0 at l(3) > > li 3, 0 > > bl foo > > nop > > addi 1, 1, 112 > > ld 0, 16(1) > > mtlr 0 > > blr > > > > Which is correct, however for the JIT one generated in memory the relocations generate some issues. > > > > First the 'lis 3, .LCPI1_0 at ha' can possible overflow which will generate an wrong relocation. > > Since the const dat...

I have updated the klibc patchset based on feedback received. In particular, the patchset has been reorganized so as not to break git-bisect. Additionally, this updates the patch base to 2.6.17-git12 (d38b69689c349f35502b92e20dafb30c62d49d63) and klibc 1.4.8; the main difference on the klibc side is removal of obsolete code. This is also available as a git tree at: