search for: ldmia

...dm/stm commands 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 sho...

...l pass after register allocation. But ldm/stm commands 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" stra...

...r, [sp, #-12] + + mrs r0, spsr + mov lr, #\offset + str r0, [sp, #-8] + str lr, [sp, #-4] + + sub r0, sp, #16 + + 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 + ldmi...

...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. >>&gt...

...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...

...char *stack) .global iir_mem16 iir_mem16: stmdb sp!, { r4-r11, lr } ldr r5, [sp, #36] @ r0 = x, r1 = den, r2 = y, r3 = N ldr r4, [sp, #40] @ r4 = mem, r5 = ord cmp r5, #10 beq .order_10 cmp r5, #8 beq .order_8 ldmia sp!, { r4-r11, pc } @ Mon-supported order, return @ TODO: try using direct form 1 filtering .order_8: ldmia r4, { r5-r12 } @ r5-r12 = mem[0..7] 0: ldrsh r14, [r0], #2 add r5, r5, #4096 @ Rounding constant str r0, [sp,#-4]! @ push r...

...: Bill Pringlemeir <bpringle at sympatico.ca> diff --git a/usr/klibc/arch/arm/setjmp.S b/usr/klibc/arch/arm/setjmp.S index 92ffc43..9f96274 100644 --- a/usr/klibc/arch/arm/setjmp.S +++ b/usr/klibc/arch/arm/setjmp.S @@ -40,10 +40,9 @@ setjmp: .type longjmp, #function longjmp: ldmia r0, {r4, r5, r6, r7, r8, r9, r10, fp, sp, lr} - mov r0, r1 - bne 1f - mov r0, #1 -1: BX(lr) + movs r0, r1 + moveq r0, #1 + BX(lr) .size longjmp,.-longjmp #else /* __thumb__ */

...-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 defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__) mov pc, lr +#else + bx lr +#endif .size longjmp,.-longjmp #else /* __thumb__ */ @@ -75,7 +83,11 @@ setjmp: mov r7, sp stmia r0!, {r3, r4, r5, r6, r7} mov r0, #0 +#if d...

...# 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__ */ + +# +# Thumb version +# +# The jmp_buf is assumed to contain the following, in order: +# lr +# r4 +# r5 +# r6 +# r7 +# r8 +# r9 +# r10 +# fp +# sp +# + + .text + .ba...

On Feb 17, 2011, at 10:35 PM, Вадим Марковцев wrote: > Hello everyone, > > I've added the "S" suffixed versions of ARM and Thumb2 instructions to tablegen. Those are, for example, "movs" or "muls". > Of course, some instructions have already had their twins, such as add/adds, and I leaved them untouched. Adding separate "s" instructions is

Hello everyone, I've added the "S" suffixed versions of ARM and Thumb2 instructions to tablegen. Those are, for example, "movs" or "muls". Of course, some instructions have already had their twins, such as add/adds, and I leaved them untouched. Besides, I propose the codegen optimization based on them, which removes the redundant comparison in patterns like orr

On Tue, 19 Jun 2012, Steve McIntyre wrote: > > More debugging results: > > * If I replace -Os with -O0 to disable optimisation, the crash goes > away too. Suggests (maybe) a compiler bug here... nasty. :| > * There's a real bug in the ARM assembly version of longjmp in > usr/klibc/arch/arm/setjmp.S: it will always pass back its first > argument as a

...7 +++---- 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/usr/klibc/arch/arm/setjmp.S b/usr/klibc/arch/arm/setjmp.S index 92ffc43..9f96274 100644 --- a/usr/klibc/arch/arm/setjmp.S +++ b/usr/klibc/arch/arm/setjmp.S @@ -40,10 +40,9 @@ setjmp: .type longjmp, #function longjmp: ldmia r0, {r4, r5, r6, r7, r8, r9, r10, fp, sp, lr} - mov r0, r1 - bne 1f - mov r0, #1 -1: BX(lr) + movs r0, r1 + moveq r0, #1 + BX(lr) .size longjmp,.-longjmp #else /* __thumb__ */

...usr/klibc/arch/arm/setjmp.S | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/usr/klibc/arch/arm/setjmp.S b/usr/klibc/arch/arm/setjmp.S index 6018bda..d351e0e 100644 --- a/usr/klibc/arch/arm/setjmp.S +++ b/usr/klibc/arch/arm/setjmp.S @@ -41,7 +41,9 @@ setjmp: longjmp: ldmia r0, {r4, r5, r6, r7, r8, r9, r10, fp, sp, lr} mov r0, r1 - BX(lr) + bne 1f + mov r0, #1 +1: BX(lr) .size longjmp,.-longjmp #else /* __thumb__ */

A few days ago, I tried to change the optimization flag from -O0 to -O2 to speed up the execution of the application on Ubuntu/ARM 14.04 32 bit. When I compiled the source code with -O2 flag instead of -O0 flag, I could not run the application normally by getting always the segmentation fault. Here is debugging information with GDB command in case of that. As you can see, we could not execute

...@ # 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 +77,7 @@ setjmp: mov r7, sp stmia r0!, {r3, r4, r5, r6, r7} mov r0, #0 - mov pc, lr + BX(lr) .size setjmp,.-setjmp .text @@ -96,7 +98,7 @@ longjmp...

...instructions are ARM mode + + stmdb sp!, { r4, lr } @ preserve 8 byte stack alignment +#ifdef __ARMEB__ + mov lr, r1 + umull r1, r12, r3, lr + mla r0, r3, r0, r12 + mla r0, r2, lr, r0 +#else + mov lr, r0 + umull r0, r12, r2, lr + mla r1, r2, r1, r12 + mla r1, r3, lr, r1 +#endif +#ifdef __thumb__ + ldmia sp!, { r4, lr } + bx lr @ back to Thumb mode +#else + ldmia sp!, { r4, pc } +#endif + + .size __muldi3,.-__muldi3 + diff -ruN klibc-0.114_orig/klibc/arch/arm/libgcc/_call_via_fp.S klibc-0.114/klibc/arch/arm/libgcc/_call_via_fp.S --- klibc-0.114_orig/klibc/arch/arm/libgcc/_call_via_fp.S 1969-12-31...

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