This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown
- From: "rguenth at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 25 Oct 2007 08:55:25 -0000
- Subject: [Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown
- References: <bug-32921-682@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #36 from rguenth at gcc dot gnu dot org 2007-10-25 08:55 -------
One reason why we see a regression here regarding to partitioning is that the
fortran FE now inlines allocate () producing three calls instead of one, which
spoils the partitioning heuristics:
{
void * D.1028;
logical4 D.1027;
int8 size.0;
int8 D.1025;
qs.dtype = 537;
qs.dim[0].lbound = 0;
qs.dim[0].ubound = (int8) (imax + -1);
qs.dim[0].stride = 1;
D.1025 = (int8) (imax + -1) + 1;
D.1027 = imax <= 0;
if (D.1027)
{
size.0 = 0;
}
else
{
size.0 = D.1025 * 8;
}
if (qs.data == 0B)
{
{
void * D.1030;
int8 D.1029;
D.1029 = size.0;
if (D.1029 < 0)
{
_gfortran_runtime_error (&"Attempt to allocate negative amount of
memory. Possible integer overflow"[1]{lb: 1 sz: 1});
}
else
{
D.1030 = __builtin_malloc (MAX_EXPR <D.1029, 1>);
if (D.1030 == 0B)
{
_gfortran_os_error (&"Out of memory"[1]{lb: 1 sz: 1});
}
}
D.1028 = D.1030;
}
}
else
{
_gfortran_runtime_error (&"Attempting to allocate already allocated
array"[1]{lb: 1 sz: 1});
}
qs.data = D.1028;
qs.offset = 0;
}
if we mark the error functions as having no VOPs (I don't see that we need
to preserve or order memory operations for these particular functions that
do not return) then this should clean up the number of VOPs considerably.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921