[Bug target/56102] New: Wrong rtx cost calculated for Thumb1

[Bug target/56102] New: Wrong rtx cost calculated for Thumb1

[amker.cheng at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56102

             Bug #: 56102
           Summary: Wrong rtx cost calculated for Thumb1
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: amker.cheng@gmail.com


For below program:

double g = 1.0;
double func(int a, double d)
{
    if (a > 0)
    return 0.0 + g;
    else
    return 2.0 + d;
}

compiling with:
./arm-none-eabi-gcc -mthumb -mcpu=cortex-m0 -Os test.c -S -o test.S

The assembly code is:
    .cpu cortex-m0
    .fpu softvfp
    .eabi_attribute 20, 1
    .eabi_attribute 21, 1
    .eabi_attribute 23, 3
    .eabi_attribute 24, 1
    .eabi_attribute 25, 1
    .eabi_attribute 26, 1
    .eabi_attribute 30, 4
    .eabi_attribute 34, 0
    .eabi_attribute 18, 4
    .code    16
    .file    "main.c"
    .global    __aeabi_dadd
    .text
    .align    1
    .global    func
    .code    16
    .thumb_func
    .type    func, %function
func:
    push    {r3, lr}
    cmp    r0, #0
    ble    .L2
    ldr    r3, .L6+16
    ldr    r0, [r3]
    ldr    r1, [r3, #4]
    ldr    r3, .L6+4
    ldr    r2, .L6
    b    .L4
.L2:
    mov    r0, r2
    mov    r1, r3
    ldr    r2, .L6+8
    ldr    r3, .L6+12
.L4:
    bl    __aeabi_dadd
    @ sp needed
    pop    {r3, pc}
.L7:
    .align    3
.L6:
    .word    0
    .word    0
    .word    0
    .word    1073741824
    .word    .LANCHOR0
    .size    func, .-func
    .global    g
    .data
    .align    3
    .set    .LANCHOR0,. + 0
    .type    g, %object
    .size    g, 8
g:
    .word    0
    .word    1072693248
    .ident    "GCC: (GNU) 4.8.0 20130122 (experimental)"

The problem is double word constant isn't split by GCC, causing bigger code
size.

[Bug target/56102] Wrong rtx cost calculated for Thumb1

[amker.cheng at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56102

--- Comment #1 from bin.cheng <amker.cheng at gmail dot com> 2013-01-25 03:46:59 UTC ---
I have investigated this issue.

GCC uses function init_lower_subreg to initialize costs of MOVE insn with
different mode, then uses this information to decompose multi-word pseudo
registers into individual registers.

The problem is ARM backend returns wrong rtx cost for SET insn with multi-word
mode. Specifically, if you define LOG_COSTS in lower-subreg.c, GCC will dump
rtx costs when compiling with:

arm-none-eabi-gcc -mthumb -mcpu=cortex-m0 -Os/-O2 ....

The dump is:
Size costs
==========

SI move: from zero cost 4, from reg cost 4
DI move: original cost 4, split cost 4 * 2
TI move: original cost 4, split cost 4 * 4
EI move: original cost 4, split cost 4 * 6
OI move: original cost 4, split cost 4 * 8
CI move: original cost 4, split cost 4 * 12
XI move: original cost 4, split cost 4 * 16
DQ move: original cost 4, split cost 4 * 2
TQ move: original cost 4, split cost 4 * 4
UDQ move: original cost 4, split cost 4 * 2
UTQ move: original cost 4, split cost 4 * 4
DA move: original cost 4, split cost 4 * 2
TA move: original cost 4, split cost 4 * 4
UDA move: original cost 4, split cost 4 * 2
UTA move: original cost 4, split cost 4 * 4
DF move: original cost 4, split cost 4 * 2
XF move: original cost 4, split cost 4 * 3
DD move: original cost 4, split cost 4 * 2
TD move: original cost 4, split cost 4 * 4
CSI move: original cost 4, split cost 4 * 2
CDI move: original cost 4, split cost 4 * 4
CTI move: original cost 4, split cost 4 * 8
CEI move: original cost 4, split cost 4 * 12
COI move: original cost 4, split cost 4 * 16
CCI move: original cost 4, split cost 4 * 24
CXI move: original cost 4, split cost 4 * 32
SC move: original cost 4, split cost 4 * 2
DC move: original cost 4, split cost 4 * 4
XC move: original cost 4, split cost 4 * 6
V8QI move: original cost 4, split cost 4 * 2
V4HI move: original cost 4, split cost 4 * 2
V2SI move: original cost 4, split cost 4 * 2
V16QI move: original cost 4, split cost 4 * 4
V8HI move: original cost 4, split cost 4 * 4
V4SI move: original cost 4, split cost 4 * 4
V2DI move: original cost 4, split cost 4 * 4
V4HF move: original cost 4, split cost 4 * 2
V2SF move: original cost 4, split cost 4 * 2
V8HF move: original cost 4, split cost 4 * 4
V4SF move: original cost 4, split cost 4 * 4
V2DF move: original cost 4, split cost 4 * 4

Speed costs
===========

SI move: from zero cost 4, from reg cost 4
DI move: original cost 4, split cost 4 * 2
TI move: original cost 4, split cost 4 * 4
EI move: original cost 4, split cost 4 * 6
OI move: original cost 4, split cost 4 * 8
CI move: original cost 4, split cost 4 * 12
XI move: original cost 4, split cost 4 * 16
DQ move: original cost 4, split cost 4 * 2
TQ move: original cost 4, split cost 4 * 4
UDQ move: original cost 4, split cost 4 * 2
UTQ move: original cost 4, split cost 4 * 4
DA move: original cost 4, split cost 4 * 2
TA move: original cost 4, split cost 4 * 4
UDA move: original cost 4, split cost 4 * 2
UTA move: original cost 4, split cost 4 * 4
DF move: original cost 4, split cost 4 * 2
XF move: original cost 4, split cost 4 * 3
DD move: original cost 4, split cost 4 * 2
TD move: original cost 4, split cost 4 * 4
CSI move: original cost 4, split cost 4 * 2
CDI move: original cost 4, split cost 4 * 4
CTI move: original cost 4, split cost 4 * 8
CEI move: original cost 4, split cost 4 * 12
COI move: original cost 4, split cost 4 * 16
CCI move: original cost 4, split cost 4 * 24
CXI move: original cost 4, split cost 4 * 32
SC move: original cost 4, split cost 4 * 2
DC move: original cost 4, split cost 4 * 4
XC move: original cost 4, split cost 4 * 6
V8QI move: original cost 4, split cost 4 * 2
V4HI move: original cost 4, split cost 4 * 2
V2SI move: original cost 4, split cost 4 * 2
V16QI move: original cost 4, split cost 4 * 4
V8HI move: original cost 4, split cost 4 * 4
V4SI move: original cost 4, split cost 4 * 4
V2DI move: original cost 4, split cost 4 * 4
V4HF move: original cost 4, split cost 4 * 2
V2SF move: original cost 4, split cost 4 * 2
V8HF move: original cost 4, split cost 4 * 4
V4SF move: original cost 4, split cost 4 * 4
V2DF move: original cost 4, split cost 4 * 4


The original MOVE insn with multi-word mode has lower costs then split insns,
thus preventing gcc from splitting.

Root cause is that thumb1_rtx_costs/thumb1_size_rtx_costs does not handle
SET/ASHIFT/ASHIFTRT/LSHIFTRT/ROTATERT patterns with multi-word mode, as
rtx_cost does.

I am working on this and will send a patch.

[Bug target/56102] Wrong rtx cost calculated for Thumb1

[amker.cheng at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56102

--- Comment #2 from bin.cheng <amker.cheng at gmail dot com> 2013-01-25 07:25:34 UTC ---
Created attachment 29270
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29270
correct test case

The previous test case is not appropriate, because gcc won't split even with
correct thumb1_rtx_cost.
Here attaches the right test case.

[Bug target/56102] Wrong rtx cost calculated for Thumb1

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56102

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-08-05
                 CC|                            |ramana at gcc dot gnu.org
   Target Milestone|---                         |4.9.0
     Ever confirmed|0                           |1

--- Comment #3 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
Is this now fixed by 

http://gcc.gnu.org/ml/gcc-cvs/2013-03/msg00784.html

[Bug target/56102] Wrong rtx cost calculated for Thumb1

[amker.cheng at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56102

bin.cheng <amker.cheng at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #4 from bin.cheng <amker.cheng at gmail dot com> ---
Yes, it's fixed by that checkin.