This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/49357] New: [4.7 Regression] register allocation worse
- From: "hp at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 10 Jun 2011 02:53:55 +0000
- Subject: [Bug rtl-optimization/49357] New: [4.7 Regression] register allocation worse
- Auto-submitted: auto-generated
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: unassigned@gcc.gnu.org
ReportedBy: hp@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.