search for: ldmfd

...ly, the distance between GVs are not fixed yet. PS: Below is the GCC output with "extern" hidden: ldr r2, .L2 stmfd sp!, {r3, lr} .save {r3, lr} .LPIC0: add r0, pc, r2 bl _Z4initPv(PLT) ldr r1, .L2+4 .LPIC1: add r0, pc, r1 bl _Z4initPv(PLT) ldr r0, .L2+8 .LPIC2: add r0, pc, r0 ldmfd sp!, {r3, lr} b _Z4initPv(PLT) .L3: .align 2 .L2: .word g0-(.LPIC0+8) .word g1-(.LPIC1+8) .word g2-(.LPIC2+8) Thanks, Weiming Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -----Original Message----- From: Rafael Espíndola [mailto:rafael.e...

...eGen/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. Running pass 'ARM Instruction Selection...

...ed directly: ldr r4, .L2 .LPIC0: add r4, pc, r4 è get &g0 via GOT_PC Relative mov r0, r4 bl _Z4initPv(PLT) add r0, r4, #400 è get &g1 bl _Z4initPv(PLT) add r0, r4, #800 è get &g2 ldmfd sp!, {r4, lr} b _Z4initPv(PLT) .L3: .align 2 .L2: .word .LANCHOR0-(.LPIC0+8) è 1 GOT offset entry It seems it’s a missing optimizing opportunity for LLVM both in code size and performance, any ideas? If so, I can open a bug and try to fix it. Thanks,...

Hi Tim, thanks for the swift response! @debug is defined in the same module, which makes this all the more confusing. The target information from the working example are: target datalayout = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64" target triple = "armv6kz--linux-gnueabihf" from the ghc produced module: target datalayout =

...s.h> -#include <asm/system.h> #include <asm/asm-offsets.h> .macro v7_way_op, op @@ -49,7 +48,7 @@ 50: .endm .text -PRIVATE(v7_flush_cache_all) +ENTRY(cpu_flush_cache_all) stmfd sp!, {r4-r5, r7, r9-r11, lr} v7_way_op c14 @@ -59,9 +58,7 @@ PRIVATE(v7_flush_cache_all) ldmfd sp!, {r4-r5, r7, r9-r11, lr} mov pc, lr -DECLARE_CPU_OP(cpu_flush_cache_all, v7_flush_cache_all) - -PRIVATE(v7_flush_cache_range) +ENTRY(cpu_flush_cache_range) mrc p15, 1, r3, c0, c0, 0 @ read CSIDR and r3, r3, #7 @ cache line size encoding mov r3, #16 @ size offset @@ -74,...

...ruction: `movne lr,pc' /tmp/ccYAgFFY.s:62: Error: no such instruction: `movne pc,r3' /tmp/ccYAgFFY.s:64: Error: expecting operand after ','; got nothing /tmp/ccYAgFFY.s:65: Error: invalid char '[' beginning operand 2 `[r5' /tmp/ccYAgFFY.s:66: Error: no such instruction: `ldmfd sp!,{r4,r5,pc}' /tmp/ccYAgFFY.s:77: Error: junk at end of line, first unrecognized character is `@' /tmp/ccYAgFFY.s:78: Error: junk at end of line, first unrecognized character is `@' /tmp/ccYAgFFY.s:79: Error: invalid char '[' beginning operand 2 `[sp' /tmp/ccYAgFFY.s:82: E...

...Return the new register table, taking it from Stg's R1 (ARM's R7). */ "mov %0, r7\n\t" /* * restore callee-saves registers. */ #if !defined(arm_HOST_ARCH_PRE_ARMv6) "vldmia sp!, {d8-d11}\n\t" #endif "ldmfd sp!, {r4-r10, fp, ip, lr}\n\t" : "=r" (r) : "r" (f), "r" (basereg), "i" (RESERVED_C_STACK_BYTES) #if !defined(__thumb__) /* In ARM mode, r11/fp is frame-pointer and so we cannot mark it as clobbered. If we do so, GCC co...

On 29 June 2012 17:46, Karel Gardas <karel.gardas at centrum.cz> wrote: > Yes and no. Shortly: original GHC/ARM/LLVM port was done by Stephen on > ARMv5/Qemu IIRC. I've later added whole VFP support and ARMv7 support. The > code in GHC is properly #ifdefed, so if there is no VFP available on pre > ARMv6, then it's not used. ie. GHC STG floating points regs are then >

Hi Renato, On 06/25/12 12:13 AM, Renato Golin wrote: > Hi Karel, > > I understand this patch has already been merged (to 3.0), so don't > take my question as stopping the merge to head, I'm just making sure I > got it right... The rest looks correct. > > + CCIfType<[v2f64], CCAssignToReg<[Q4, Q5]>>, > + CCIfType<[f64], CCAssignToReg<[D8, D9,

>> Any thoughs? > > I'm now struggling to see how GCC justifies it. What if a different > translation-unit declared those variables in a different order? I also > can't get the same behaviour here, do you have a more complete > command-line? Ah, I see; the translation-unit that does the optimisation needs to have them as a definition (i.e. "= {0}") rather

...: .L6: mov r0, r3 bl __cxa_begin_catch mov r3, r0 ldr r3, [r3, #0] str r3, [fp, #-8] ldr r0, .L9+4 ldr r1, [fp, #-8] .LEHB2: bl printf .LEHE2: bl __cxa_end_catch mov r3, #0 mov r0, r3 sub sp, fp, #4 ldmfd sp!, {fp, lr} bx lr .L10: .align 2 .L9: .word _ZTIi .word .LC0 .global __gxx_personality_v0 .personality __gxx_personality_v0 .handlerdata .align 2 .LLSDA6: .byte 0xff .byte 0 .uleb128 .LLSDATT6-.LLSDATTD6 .LLSDATT...

...the swi, unless + we are compiled in EABI mode */ + + .balign 4 +__syscall_common: +#ifdef __ARM_EABI__ + ldr r4, [sp,#16] + ldr r5, [sp,#20] + ldr r7, [lr] + swi 0 +#endif + cmn r0, #4096 + rsbcs r2, r0, #0 + ldrcs r3, 1f + mvncs r0, #0 + strcs r2, [r3] + ldmfd sp!,{r4,r5,r7,pc} + + .balign 4 +1: + .word errno + +#else + /* Thumb version - must still load r4 and r5 and run swi */ + + .thumb_func + .balign 2 +__syscall_common: + mov r7, lr + ldr r4, [sp,#16] + sub r7, #1 /* Remove the Thumb bit */ + ldr r5, [sp,#20] + ldrh r7, [r7] + swi 0 + ldr r1, 2f +...

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

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

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

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: