This is the mail archive of the
mailing list for the GCC project.
Re: GCC inline parameters (PR 10160 testcase)
Steven Bosscher <email@example.com> 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.
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);
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 <firstname.lastname@example.org>