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

            Bug ID: 105028
           Summary: gcc.dg/long_branch.c compilation time increases by 10x
                    on BE system after r11-5648
           Product: gcc
           Version: 11.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Starting back in gcc 11 there were a couple of test case compilations that
started to time out on our older BE systems.  The most common one was
gcc.dg/long_branch.c.  It happened so rarely I never got back to investigating
if it was always this way or there was some recent change.

I finally tracked it down to r11-5648.  Note it also happens in trunk.  Before
the change on a power 7 long_branch.c takes about 4s to compile with -m32 and
5.5s with -m64 (varies a bit between runs).  With r11-5648 that changes to 50+s
and 9s respectively.  On a busy system that 50s can stretch out long enough to
hit the 300 second ulimit set for test case compilations and thus they time
out. The time change increases are similar on a power 8 BE machine, too, but as
they are faster they never hit the timeout.

I see no difference in compilation time on an LE system.

I looked using -ftime-report at what was taking more time and saw these:

g:337d6362458ab033d3bfe287dda37f9da5577406, r11-5647:
 phase opt and generate             :   3.89 ( 97%)   0.04 ( 44%)   3.92 ( 95%)
   43M ( 91%)
 callgraph functions expansion      :   3.23 ( 80%)   0.02 ( 22%)   3.25 ( 79%)
   32M ( 68%)
 integrated RA                      :   0.23 (  6%)   0.00 (  0%)   0.23 (  6%)
   12M ( 26%)

g:037fe26ee1ac18581bf0ad646d48591c97d10bd3, r11-5648:
 phase opt and generate             :  32.86 (100%)   0.16 ( 73%)  33.02 ( 99%)
  205M ( 98%)
 callgraph functions expansion      :  32.28 ( 98%)   0.14 ( 64%)  32.42 ( 98%)
  194M ( 93%)
 integrated RA                      :  20.70 ( 63%)   0.08 ( 36%)  20.79 ( 63%)
   50M ( 24%)

The latter run had a few more phases that ran, too.

So, is this a real problem or a "just live with it" thing?


commit 037fe26ee1ac18581bf0ad646d48591c97d10bd3
Author: Jakub Jelinek <ja...@redhat.com>
Date:   Wed Dec 2 11:32:19 2020 +0100

    expansion: Further improve double-word modulo, division and divmod
[PR97459]

Reply via email to