[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown

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