------- 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