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

           Summary: [4.7 Regression] register allocation worse
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
        AssignedTo: unassig...@gcc.gnu.org
        ReportedBy: h...@gcc.gnu.org
              Host: x86_64-unknown-linux-gnu
            Target: cris-axis-elf


Compare the prologue for the test-case in attachment 24471 to PR49154 and
compiled according to those instructions,
<http://gcc.gnu.org/bugzilla/attachment.cgi?id=24471> between 4.3.3 (everything
before the first "add"):
    subq 4,$sp
    move $srp,[$sp]
    subq 12,$sp
    movem $r2,[$sp]
    move.d $r10,$r2
    move.d $r10,$r9
    move.d $r11,$r10

to that of trunk at r174114 as well as r174870:
        subq 4,$sp
        move $srp,[$sp]
        subq 16,$sp
        movem $r3,[$sp]
        subq 4,$sp
        move.d $r8,[$sp]
        move.d $r10,$r8
        move.d $r11,$r9

So, we have a regression from 3 to 5 registers, and with a hole compared to
reg_alloc_order.  Note that the source uses DFmode and DImode and derived
unions; at a glance "normal" code is less affected.  Building on a 32-bit host
seems to aggravate the situation.

Just put here as a note for the time being.

Reply via email to