This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC inline parameters (PR 10160 testcase)

Steven Bosscher <> writes:

> > The end of that PR points at a quadratic algorithm elsewhere in the
> > compiler.
> In PR 10155, there is a _huge_ increase in memory.
>  > The increase in memory at -O3 is a result of unit at a
>  > time compilation (which is why I CC you, Honza).  You
>  > can check that by compiling with -O2 + all flags enabled
>  > at -O3 except -funit-at-a-time:
>  > > Loop unswitching is responsible for most of the compile
>  Zdenek, this really ought not to happen, what is going on?
>  > time increase.

Oh, that.

I encountered something very much this in a much more severe context.

I'd suggest you try these things:

1. Place a ggc_collect here in loop.c:

  /* Now scan the loops, last ones first, since this means inner ones are done
     before outer ones.  */
  for (i = max_loop_num - 1; i >= 0; i--)
      struct loop *loop = &loops->array[i];
      if (! loop->invalid && loop->end)
        scan_loop (loop, flags);

      ggc_collect ();

2. If this works (it would limit memory use at the cost of
   dramatically longer optimisation), go to cselib_init in cse.c, and
   either (a) create the two varrays slightly larger than cselib_nregs
   so that it's more likely they can be reused, or (b) arrange for
   ggc_realloc to be used which I think is the preferred solution.

I hit this one with a routine, the result of inlining and soon to be a
real-life example, where max_loop_num was over 4000 and cselib_nregs
was about 120k.

- Geoffrey Keating <>

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]