This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/32855] [4.3 Regression] g++.dg/tree-ssa/pr28003.C
- From: "jakub at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 20 Aug 2007 18:25:49 -0000
- Subject: [Bug target/32855] [4.3 Regression] g++.dg/tree-ssa/pr28003.C
- References: <bug-32855-682@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #3 from jakub at gcc dot gnu dot org 2007-08-20 18:25 -------
Wow, scheduling plus reload does extremely horrible job here.
This is
b[0] = {};
b[0].a.j[0] = 0;
b[0].a.j[1] = 0;
b[0].a.j[2] = 0;
b[0].a.j[3] = 0;
b[0].a.j[4] = 0;
b[0].a.j[5] = 0;
b[0].a.j[6] = 0;
b[0].a.j[7] = 0;
b[0].a.j[8] = 0;
b[0].a.i = 1;
repeated 25 times in *.optimized dump, in *.expand that's 250 stores to b
array,
in the increasing index order and we are storing just 0s or 1s. So ideally
on IA-64 we would use just 1 reg to store 1, and two or 4 registers to store
pointers and use auto-increment. But after scheduling we have huge amount of
overlapping live ranges for the many pointer pseudos and reload decides to put
them wherever possible, all kinds of general regs, reg window regs, and after
the dataflow even into b0 without bothering to restore it properly.
Vlad, is your RA capable of handling this more sanely?
--
jakub at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vmakarov at gcc dot gnu dot
| |org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32855