This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: tree-ssa memory and compile-time regressions
> > On Thu, 8 Jan 2004, Jan Hubicka wrote:
> >
> > > > Hi!
> > > >
> > > > I just tried todays tree-ssa branch (wanting to look at tree-sra and
> > > > tree-points-to=andersen) with POOMA and experience problems
> > > > getting my application to finish compiling at all...
> > > >
> > > > Looking at the testcase (stripped down application)
> > > > http://www.tat.physik.uni-tuebingen.de/~rguenth/gcc/apressure.ii.gz
> > > >
> > > > timings are (1GHz Athlon, 1G ram), all with -fno-exceptions:
> > > >
> > > > -O0 220MB, 0m17s
> > > > -O1 260MB, 0m24s
> > > > -O2 800MB, 7m35s (-ftime-report on a faster machine attached below)
> > > > -O2 -fno-unit-at-a-time 260MB, 0m28s
> > >
> > > It seems to me that inlining just drives ssa-pre pass crazy.
> > > You can take a look into -dU dump, it contains information about what
> > > functions get inlinined where and the overall growth.
> > > In general the growth shall never exceed 100% so this seems to be either
> > > very nonlinear behaviour of something in the size of function or bug in
> > > code size estimation.
> >
> > F.i.
> >
> > Deciding on smaller functions:
> >
> > Considering Interval<Dim>::~Interval() [with int Dim = 3] with 0 insns
> > Estimated growth is -1390 insns.
> > Inlined into EvaluateLocLoop<Forgas::APressure<3>, 3>::~EvaluateLocLoop()
> > which now has -10 insns.
> > Inlined into INode<Dim>::~INode() [with int Dim = 3] which now has -10
> > insns.
> > ...
> >
> > negative code sizes don't look right? So out of zero instruction inline
> > we generate -1390 instructions? Here's something wrong. Like (unchecked):
>
> THis should not happen as size of call is 10 and thus the size should
> never get negative. I will add abort here and figure out what is going
> on.
I can not get to your website for some reason, but I would guess that
the attached patch will fix it. I cut&pasted the new nodes to wrong
place in function so we didn't count anything embeded in EH regions.
Honza
Index: tree-inline.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree-inline.c,v
retrieving revision 1.26.2.75
diff -c -3 -p -r1.26.2.75 tree-inline.c
*** tree-inline.c 4 Jan 2004 15:48:30 -0000 1.26.2.75
--- tree-inline.c 8 Jan 2004 21:52:21 -0000
*************** estimate_num_insns_1 (tree *tp, int *wal
*** 1216,1232 ****
case STATEMENT_LIST:
case ERROR_MARK:
case NON_LVALUE_EXPR:
- break;
- /* We don't account constants for now. Assume that the cost is amortized
- by operations that do use them. We may re-consider this decision once
- we are able to optimize the tree before estimating it's size and break
- out static initializers. */
- case IDENTIFIER_NODE:
- case INTEGER_CST:
- case REAL_CST:
- case COMPLEX_CST:
- case VECTOR_CST:
- case STRING_CST:
case ENTRY_VALUE_EXPR:
case FDESC_EXPR:
case VA_ARG_EXPR:
--- 1216,1221 ----
*************** estimate_num_insns_1 (tree *tp, int *wal
*** 1242,1247 ****
--- 1231,1247 ----
case EPHI_NODE:
case EEXIT_NODE:
case PHI_NODE:
+ break;
+ /* We don't account constants for now. Assume that the cost is amortized
+ by operations that do use them. We may re-consider this decision once
+ we are able to optimize the tree before estimating it's size and break
+ out static initializers. */
+ case IDENTIFIER_NODE:
+ case INTEGER_CST:
+ case REAL_CST:
+ case COMPLEX_CST:
+ case VECTOR_CST:
+ case STRING_CST:
*walk_subtrees = 0;
return NULL;
/* Reconginze assignments of large structures and constructors of