search for: stmfd

Hi I write a machinefunction pass to print all the machinefunction's machine instructions. My target architecture is ARM. However, I don't understand some part of the machine instructions. Below is some of the assembly language for function A. .text:0001C034 STMFD SP!, {R4,R10,R11,LR} > .text:0001C038 ADD R11, SP, #8 > .text:0001C03C SUB SP, SP, #0x20 > .text:0001C040 STR R0, [R11,#statbuf] > .text:0001C044 STR R1, [SP,#0x28+var_14] > .text:0001C048...

...unction's >> machine instructions. >> >> My target architecture is ARM. However, I don't understand some part of >> the machine instructions. >> >> Below is some of the assembly language for function A. >> >> .text:0001C034 STMFD SP!, {R4,R10,R11,LR} >> .text:0001C038 ADD R11, SP, #8 >> .text:0001C03C SUB SP, SP, #0x20 >> .text:0001C040 STR R0, [R11,#statbuf] >> .text:0001C044 STR R1, [SP,#0x28+var_14] &...

Hi Rafael, Yes, merging gv prevents linker to do garbage collection. Should it be implemented as a peephole pass? If we do it too early, 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...

...d tests in the patch runs fine for me :) Now something fun this Generic test now works that 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 |...

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 =

...tion\n"; + print OUT " .globl ${fname}\n"; + + print OUT "#ifndef __thumb__\n"; + + print OUT "#ifndef __ARM_EABI__\n"; + + # ARM version first + print OUT " .balign 4\n"; + print OUT "${fname}:\n"; + print OUT " stmfd sp!,{r4,r5,lr}\n"; + print OUT " ldr r4,[sp,#12]\n"; + print OUT " ldr r5,[sp,#16]\n"; + print OUT " swi # __NR_${sname}\n"; + print OUT " b __syscall_common\n"; + + print OUT "#else /* __ARM_EABI__ */\n"; + + # ARM EABI...

...config.h> +#include <asm/asm-macros.h> #include <asm/page.h> -#include <asm/cpu-ops.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 @...

...I do "make $BUILDOPTIONS" /tmp/ccYAgFFY.s: Assembler messages: /tmp/ccYAgFFY.s:36: Error: junk at end of line, first unrecognized character is `@' /tmp/ccYAgFFY.s:37: Error: junk at end of line, first unrecognized character is `@' /tmp/ccYAgFFY.s:38: Error: no such instruction: `stmfd sp!,{r4,r5,lr}' /tmp/ccYAgFFY.s:39: Error: no such instruction: `ldr r5,.L14' /tmp/ccYAgFFY.s:40: Error: no such instruction: `ldrb r3,[r5,' /tmp/ccYAgFFY.s:41: Error: expecting operand after ','; got nothing /tmp/ccYAgFFY.s:42: Error: no such instruction: `ldmnefd sp!,{r4,r5,pc...

everyone-- I'm trying to build LLVM-GCC as a cross-compiler for a new target. I've successfully patched binutils, the FSF GCC, LLVM and Clang to build for this new target-- they work fine, but the LLVM-gcc build is failing for me. All my llvm.org sources are tracking the Subversion trunk, but my problem is probably not related to any ongoing churn there. I'm doing something

...define THUMB_FUNC ".thumb\n\t.thumb_func\n\t" #else #define THUMB_FUNC #endif StgRegTable * StgRun(StgFunPtr f, StgRegTable *basereg) { StgRegTable * r; __asm__ volatile ( /* * save callee-saves registers on behalf of the STG code. */ "stmfd sp!, {r4-r10, fp, ip, lr}\n\t" #if !defined(arm_HOST_ARCH_PRE_ARMv6) "vstmdb sp!, {d8-d11}\n\t" #endif /* * allocate some space for Stg machine's temporary storage. * Note: RESERVER_C_STACK_BYTES has to be a round number here or * t...

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

....ascii "Exception Nr %d occurred\012\000" .text .align 2 .global main .type main, %function main: .fnstart .LFB6: @ Function supports interworking. @ args = 0, pretend = 0, frame = 8 @ frame_needed = 1, uses_anonymous_args = 0 stmfd sp!, {fp, lr} .save {fp, lr} .setfp fp, sp, #4 add fp, sp, #4 .pad #8 sub sp, sp, #8 mov r0, #4 bl __cxa_allocate_exception mov r3, r0 mov r2, #20 str r2, [r3, #0] mov r0, r3 ldr r1, .L9 mov r2, #0 .LE...

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

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

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: