optimization/3977: arm peephole for loading two consecutive memory locations generates suboptimal code (on arm7tdmi)

optimization/3977: arm peephole for loading two consecutive memory locations generates suboptimal code (on arm7tdmi)

[segher]

>Number:         3977
>Category:       optimization
>Synopsis:       arm peephole for loading two consecutive memory locations generates suboptimal code (on arm7tdmi)
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          pessimizes-code
>Submitter-Id:   net
>Arrival-Date:   Thu Aug 09 12:46:01 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     segher@chello.nl
>Release:        3.0
>Organization:
>Environment:

>Description:
I often see generated code like

add   temp, pointer, #offset
ldmia temp, {regA, regB}

(after which temp is dead)

which is slower than just

ldr regA, [pointer, #offset]
ldr regB, [pointer, #offset+4]

and wastes a register as well
>How-To-Repeat:
a lot of code will do this
>Fix:
change the peephole, i think
>Release-Note:
>Audit-Trail:
>Unformatted:

Re: optimization/3977: arm peephole for loading two consecutive memory locations generates suboptimal code (on arm7tdmi)

[rearnsha]

Synopsis: arm peephole for loading two consecutive memory locations generates suboptimal code (on arm7tdmi)

Responsible-Changed-From-To: unassigned->rearnsha
Responsible-Changed-By: rearnsha
Responsible-Changed-When: Fri Aug 10 03:20:57 2001
Responsible-Changed-Why:
    Mine
State-Changed-From-To: open->closed
State-Changed-By: rearnsha
State-Changed-When: Fri Aug 10 03:20:57 2001
State-Changed-Why:
    Your analysis is incorrect (at least for the ARM7TDMI).
    An LDR instruction takes 3 cycles (of which 2 are N-cycles --
    non-sequential memory accesses, and 1 I-cycle -- idle). 
    An add instruction takes 1 cycle (normally an S-cycle -- sequential)
    A k-word LDM instruction takes 2+k cycles of which 2 are N-cycles
    and k-1 are S-cycles, giving 2N+1S+1I for the 2-word example in this
    case.
    
    So for the code generated we have 1S + (2N + 1I + 1S) = 2N+2S+I
    and for the two LDR instructions we have 2x(2N+I) = 4N+2I
    
    On most memory systems I cycles and S cyles will be the same
    duration, but N cycles will typically be twice as long as S cycles
    so you can easily see that the LDM sequence will in fact execute
    more quickly.
    
    It is also incorrect that this requires an additional scratch register
    -- we can always use one of the registers we are about to load
    as the scratch.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3977&database=gcc