search for: stmia

..., > what is often not so after regalloc, therefore some str/ldr commands. For > example such code: > > struct Foo {int a, b, c, d; } > void CopyStruct(struct Foo *a, struct Foo *b) { *a = *b; } > > compiled to: > > ldmia    r1, {r2, r3, r12} > ldr    r1, [r1, #12] > stmia    r0, {r2, r3, r12} > str    r1, [r0, #12] > bx    lr > > I ran different tests and always regalloc allocates at least one register > not in ascending order. > > What is your ideas to overcome this issue? Maybe llvm should emit code for > "memcpy" straight into ld...

...ommands require registers to go in ascending order, what is often not so after regalloc, therefore some str/ldr commands. For example such code: struct Foo {int a, b, c, d; } void CopyStruct(struct Foo *a, struct Foo *b) { *a = *b; } compiled to: ldmia r1, {r2, r3, r12} ldr r1, [r1, #12] stmia r0, {r2, r3, r12} str r1, [r0, #12] bx lr I ran different tests and always regalloc allocates at least one register not in ascending order. What is your ideas to overcome this issue? Maybe llvm should emit code for "memcpy" straight into ldm/stm or exchange registers before...

...>>> example such code: >>> >>> struct Foo {int a, b, c, d; } >>> void CopyStruct(struct Foo *a, struct Foo *b) { *a = *b; } >>> >>> compiled to: >>> >>> ldmia    r1, {r2, r3, r12} >>> ldr    r1, [r1, #12] >>> stmia    r0, {r2, r3, r12} >>> str    r1, [r0, #12] >>> bx    lr >>> >>> I ran different tests and always regalloc allocates at least one register >>> not in ascending order. >>> >>> What is your ideas to overcome this issue? Maybe llvm shoul...

...oc, therefore some str/ldr commands. For >> example such code: >> >> struct Foo {int a, b, c, d; } >> void CopyStruct(struct Foo *a, struct Foo *b) { *a = *b; } >> >> compiled to: >> >> ldmia r1, {r2, r3, r12} >> ldr r1, [r1, #12] >> stmia r0, {r2, r3, r12} >> str r1, [r0, #12] >> bx lr >> >> I ran different tests and always regalloc allocates at least one register >> not in ascending order. >> >> What is your ideas to overcome this issue? Maybe llvm should emit code for >> &qu...

...1: @@ -49,7 +53,11 @@ vfork: str r2, [r1] neg r0, r0 1: +#if defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__) mov pc, lr +#else + bx lr +#endif .balign 4 2: --- klibc-1.5.20.orig/usr/klibc/arch/arm/setjmp.S +++ klibc-1.5.20/usr/klibc/arch/arm/setjmp.S @@ -29,7 +29,11 @@ setjmp: stmia r0, {r4, r5, r6, r7, r8, r9, r10, fp, sp, lr} mov r0, #0 +#if defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__) mov pc, lr +#else + bx lr +#endif .size setjmp,.-setjmp .text @@ -39,7 +43,11 @@ setjmp: longjmp: ldmia r0, {r4, r5, r6, r7, r8, r9, r10, fp, sp, lr} mov r0, r1 +#if d...

...t previously failed: $ llvm-as < test/CodeGen/Generic/multiple-return-values-cross-block-with-invoke.ll | llc .file "<stdin>" .text .globl foo .align 2 foo: stmfd sp!, {r4, r5, lr} mov r4, r1 mov r5, r0 bl wild .LBB1_1: @ normal stmia r5, {r0, r1} stmia r4, {r2, r3} ldmfd sp!, {r4, r5, pc} .size foo, .-foo Some failing tests have now gotten better error reporting than before: $ llvm-as < test/CodeGen/Generic/select-cc.ll | llc Formal argument #0 has unhandled type i64 Stack dump: 0. Program arguments: llc 1....

...5]*y[i] ldrsh r0, [r1, #14] mla r11, r4, r14,r12 @ mem[6] = mem[7] - den[6]*y[i] subs r3, r3, #1 mul r12, r0, r14 @ mem[7] = -den[7]*y[i] ldr r0, [sp], #4 @ restore r0 bne 0b ldr r4, [sp, #40] @ r4 = mem stmia r4, { r5-r12 } @ Save back mem[] ldmia sp!, { r4-r11, pc } @ Exit .order_10: ldmia r4, { r5-r9 } @ r5-r9 = mem[0..4] add r5, r5, #4096 @ Rounding constant ldrsh r14, [r0], #2 add r14, r14, r5, asr #13 @ (mem[0] + 4096) >>...

...+ msr cpsr_cxsf, #(PSR_I_BIT | PSR_F_BIT | PSR_MODE_SVC) + + sub sp, sp, #CTXT_FRAME_SIZE +SPFIX( tst sp, #4 ) +SPFIX( bicne sp, sp, #4 ) + stmib sp, {r1 - lr}^ + ldmia r0, {r1 - r4} + add r5, sp, #CTXT_SSP + add r0, sp, #CTXT_FRAME_SIZE +SPFIX( addne r0, r0, #4 ) + str r1, [sp] + mov r1, lr + stmia r5, {r0 - r4} + msr spsr_cxsf, r3 +.endm + +.macro RESTORE_CONTEXT + ldr r0, [sp, #CTXT_SPSR] + msr spsr_cxsf, r0 + ldmia sp, {r0 - lr}^ + add sp, sp, #CTXT_SSP + ldmia sp, {sp, lr, pc}^ +.endm + + .align 5 + .global exception_vector_table +exception_vector_table: + ldr pc, .rst + ldr pc, .und + ld...

...rch/arm/setjmp.S b/usr/klibc/arch/arm/setjmp.S index 2232458..6018bda 100644 --- a/usr/klibc/arch/arm/setjmp.S +++ b/usr/klibc/arch/arm/setjmp.S @@ -4,6 +4,8 @@ # setjmp/longjmp for the ARM architecture # +#include <klibc/asmmacros.h> + #ifndef __thumb__ # @@ -29,7 +31,7 @@ setjmp: stmia r0, {r4, r5, r6, r7, r8, r9, r10, fp, sp, lr} mov r0, #0 - mov pc, lr + BX(lr) .size setjmp,.-setjmp .text @@ -39,7 +41,7 @@ setjmp: longjmp: ldmia r0, {r4, r5, r6, r7, r8, r9, r10, fp, sp, lr} mov r0, r1 - mov pc, lr + BX(lr) .size longjmp,.-longjmp #else /* __thumb__ */ @@ -75,7...

...r the ARM architecture +# + +#ifndef __thumb__ + +# +# "Pure ARM" version +# +# The jmp_buf is assumed to contain the following, in order: +# r4 +# r5 +# r6 +# r7 +# r8 +# r9 +# r10 +# fp +# sp +# lr +# + + .text + .balign 4 + .globl setjmp + .type setjmp, #function +setjmp: + stmia r0, {r4, r5, r6, r7, r8, r9, r10, fp, sp, lr} + mov r0, #0 + mov pc, lr + .size setjmp,.-setjmp + + .text + .balign 4 + .globl longjmp + .type longjmp, #function +longjmp: + ldmia r0, {r4, r5, r6, r7, r8, r9, r10, fp, sp, lr} + mov r0, r1 + mov pc, lr + .size longjmp,.-longjmp + +#else /* __thumb__...

After wasting an inordinate amount of time trying to get test-suite to run on arm-apple-darwin so I could reproduce your results, attached is a patch that fixes the small copy&paste error of having 8-byte alignment for stack-allocated f64s instead of the proper 4-byte. I've updated the patch to the top of trunk changes as well. deep On Fri, Feb 27, 2009 at 8:31 PM, Sandeep Patel

Hello Evan and Robert I have been investigating the unexpected test failures from the ARM nightly builders in order to get a better picture why the ARM backend don't pass the whole testsuite: I have run the failing tests manually on my arm board and can now categorize most of the thirteen unexpected CodeGen failures in four categories: 1. llvm don't lower MVT::i64 properly on arm

I'm not currently setup to be able to run the A/B comparison tests that test-suite relies upon. Fhourstones-3.1 looks to be the simplest. If you can send me the two .o files from either EABI or Darwin, I can dig into why this went wrong for you. deep On Thu, Feb 26, 2009 at 3:53 PM, Evan Cheng <echeng at apple.com> wrote: > Sorry I haven't gotten back to you earlier. I have

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:

Hello everyone, this is the fourth version of the patch series that introduces ARMv7 with virtualization extensions support in Xen. The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile Express simulator. See the following announce email for more informations about what we are trying to achieve, as well as the original git history: See

Hello everyone, this is the very first version of the patch series that introduces ARMv7 with virtualization extensions support in Xen. The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile Express simulator. See the following announce email for more informations about what we are trying to achieve, as well as the original git history: See