public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/95018] New: Excessive unrolling for Fortran library array handling
@ 2020-05-09  7:58 tkoenig at gcc dot gnu.org
  2020-05-09  8:00 ` [Bug target/95018] " tkoenig at gcc dot gnu.org
                   ` (38 more replies)
  0 siblings, 39 replies; 40+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2020-05-09  7:58 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018

            Bug ID: 95018
           Summary: Excessive unrolling for Fortran library array handling
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Created attachment 48488
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48488&action=edit
Generated assembly

The code generated for in_pack_i4.c from libgfortran on POWER9 is huge
and, presumably, slow; I assume that other code in the library is
similarly affected.

The problem manifests itself in the unrolling of the loops which
do all the work:

  while (src)
    {
      /* Copy the data.  */
      *(dest++) = *src;
      /* Advance to the next element.  */
      src += stride0;
      count[0]++;
      /* Advance to the next source element.  */
      index_type n = 0;
      while (count[n] == extent[n])
        {
          /* When we get to the end of a dimension, reset it and increment
             the next dimension.  */
          count[n] = 0;
          /* We could precalculate these products, but this is a less
             frequently used path so probably not worth it.  */
          src -= stride[n] * extent[n];
          n++;
          if (n == dim)
            {
              src = NULL;
              break;
            }
          else
            {
              count[n]++;
              src += stride[n];
            }
        }
    }
  return destptr;
}

One problem here is the while (count[n] == extent[n]) loop.
This is an odometer algorithm to look for the next element to
go to. Most of the times, the while is false, so it is definitely
not good.

x86_64 does not appear to be affected.

^ permalink raw reply	[flat|nested] 40+ messages in thread
end of thread, other threads:[~2020-06-19 14:39 UTC | newest]

Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-09  7:58 [Bug target/95018] New: Excessive unrolling for Fortran library array handling tkoenig at gcc dot gnu.org
2020-05-09  8:00 ` [Bug target/95018] " tkoenig at gcc dot gnu.org
2020-05-09  8:10 ` tkoenig at gcc dot gnu.org
2020-05-09  8:36 ` [Bug target/95018] [11 Regression] " tkoenig at gcc dot gnu.org
2020-05-09  9:01 ` tkoenig at gcc dot gnu.org
2020-05-09  9:03 ` tkoenig at gcc dot gnu.org
2020-05-09  9:42 ` [Bug target/95018] [10/11 " tkoenig at gcc dot gnu.org
2020-05-09 13:21 ` tkoenig at gcc dot gnu.org
2020-05-11  5:03 ` tkoenig at gcc dot gnu.org
2020-05-11  5:18 ` tkoenig at gcc dot gnu.org
2020-05-11  7:53 ` guojiufu at gcc dot gnu.org
2020-05-11  8:07 ` guojiufu at gcc dot gnu.org
2020-05-11  8:13 ` guojiufu at gcc dot gnu.org
2020-05-11  8:32 ` guojiufu at gcc dot gnu.org
2020-05-11  9:20 ` tkoenig at gcc dot gnu.org
2020-05-11 14:09 ` guojiufu at gcc dot gnu.org
2020-05-11 19:13 ` tkoenig at gcc dot gnu.org
2020-05-12  5:58 ` guojiufu at gcc dot gnu.org
2020-05-12  6:06 ` guojiufu at gcc dot gnu.org
2020-05-12  7:41 ` rguenth at gcc dot gnu.org
2020-05-12  7:50 ` rguenth at gcc dot gnu.org
2020-05-12  9:30 ` tkoenig at gcc dot gnu.org
2020-05-12  9:46 ` tkoenig at gcc dot gnu.org
2020-05-12 10:08 ` rguenth at gcc dot gnu.org
2020-05-12 10:27 ` rguenther at suse dot de
2020-05-13  2:33 ` guojiufu at gcc dot gnu.org
2020-05-13  2:59 ` guojiufu at gcc dot gnu.org
2020-05-13  3:37 ` guojiufu at gcc dot gnu.org
2020-05-13  6:07 ` rguenth at gcc dot gnu.org
2020-05-13  7:54 ` tkoenig at gcc dot gnu.org
2020-05-13  8:14 ` rguenth at gcc dot gnu.org
2020-05-13  9:54 ` guojiufu at gcc dot gnu.org
2020-05-13 10:14 ` rguenth at gcc dot gnu.org
2020-05-13 11:24 ` guojiufu at gcc dot gnu.org
2020-05-19  5:42 ` guojiufu at gcc dot gnu.org
2020-06-07  9:41 ` cvs-commit at gcc dot gnu.org
2020-06-08  2:54 ` guojiufu at gcc dot gnu.org
2020-06-08  5:12 ` tkoenig at gcc dot gnu.org
2020-06-09  2:50 ` guojiufu at gcc dot gnu.org
2020-06-19 14:39 ` cvs-commit at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).