ldreqd instruction in xscale

Arvind Krishnaswamy arvind@CS.Arizona.EDU
Fri Jan 25 08:03:00 GMT 2002


On 25 Jan 2002, Phil Blundell wrote:

> On Thu, 2002-01-24 at 22:12, Arvind Krishnaswamy wrote:
> > I used the -march=armv4t with both the arm-elf-gcc compiler and xscale-elf-gcc
> > compiler. But xscale-elf-gcc generates different code. The ldreqd instruction
> > is used code generated by xscale-elf-gcc bt is absent in code generated by
> > arm-elf-gcc. Doesn't -march=armv4t specify the instruction to be used?
>
> LDRD is an ARMv5E ("El Segundo") instruction.  So yes, I would expect
> -march=armv4t to suppress generation of those.  Do you have a testcase
> that shows the problem?
>
> p.
>
>
>

The following are the first few lines of the strlen function (both
arm-elf-gcc and xscale-elf-gcc were used with the -march=armv4t)
Is it because strlen comes from the libraries and that was probably
compiled without the switch? If so is there some way by which I can avoid
this?

arm-elf-gcc

0000cc20 <strlen>:
    cc20:   e52de004    str lr, [sp, -#4]!
    cc24:   e3100003    tst r0, #3  ; 0x3
    cc28:   e1a0e000    mov lr, r0
    cc2c:   0a000007    beq cc50 <strlen+0x30>
    cc30:   e5d03000    ldrb    r3, [r0]
    cc34:   e3530000    cmp r3, #0  ; 0x0
    cc38:   0a000002    beq cc48 <strlen+0x28>
    cc3c:   e5f03001    ldrb    r3, [r0, #1]!
    cc40:   e3530000    cmp r3, #0  ; 0x0
    cc44:   1afffffc    bne cc3c <strlen+0x1c>
    cc48:   e06e0000    rsb r0, lr, r0
    cc4c:   e49df004    ldr pc, [sp], #4
    cc50:   e3e0c401    mvn r12, #16777216  ; 0x1000000
    cc54:   e5902000    ldr r2, [r0]
    cc58:   e24cc801    sub r12, r12, #65536    ; 0x10000
    cc5c:   e24ccc01    sub r12, r12, #256  ; 0x100
    cc60:   e3a01902    mov r1, #32768  ; 0x8000
    cc64:   e082300c    add r3, r2, r12
    cc68:   e2811080    add r1, r1, #128    ; 0x80
    cc6c:   e1c33002    bic r3, r3, r2
    cc70:   e1811801    orr r1, r1, r1, lsl #16
    cc74:   e1130001    tst r3, r1
    ...



xscale-elf-gcc

0001062c <strlen>:
   1062c:   e3100003    tst r0, #3  ; 0x3
   10630:   e92d40f0    stmdb   sp!, {r4, r5, r6, r7, lr}
   10634:   e1a01000    mov r1, r0
   10638:   0a000005    beq 10654 <strlen+0x28>
   1063c:   e2400001    sub r0, r0, #1  ; 0x1
   10640:   e5f03001    ldrb    r3, [r0, #1]!
   10644:   e3530000    cmp r3, #0  ; 0x0
   10648:   0a00001f    beq 106cc <strlen+0xa0>
   1064c:   e3100003    tst r0, #3  ; 0x3
   10650:   1afffffa    bne 10640 <strlen+0x14>
   10654:   e3a05080    mov r5, #128    ; 0x80
   10658:   e2855902    add r5, r5, #32768  ; 0x8000
   1065c:   e0855805    add r5, r5, r5, lsl #16
   10660:   e1e04085    mvn r4, r5, lsl #1
   10664:   e3100007    tst r0, #7  ; 0x7
   10668:   01c060d0    ldreqd  r6, [r0]
   1066c:   0a000007    beq 10690 <strlen+0x64>
   10670:   e5902000    ldr r2, [r0]
   10674:   e0823004    add r3, r2, r4
   10678:   e1c33002    bic r3, r3, r2
   1067c:   e0132005    ands    r2, r3, r5
   10680:   1a00000a    bne 106b0 <strlen+0x84>
   ...

Thanks,
-Arvind



More information about the Gcc mailing list