Tree-ssa status with POOMA

[Jan Hubicka]

> On Thu, 5 Feb 2004, Jan Hubicka wrote:
> 
> > > For my real-world application I'm quite happy with tree-ssa:
> > >
> > > -O2 -funroll-loops -ffast-math -march=athlon -fno-exceptions
> > >
> > > 		memory	compile-time	run-time	stripped static size
> > > tree-ssa	450MB	3m57s		46s		1729680
> > > gcc3.4		530MB	3m16s		44s		1734596
> > >
> > > compile times are slightly in favor of 3.4, but it was compiled with a
> > > profiledbootstrap (with a usual bootstrap I remember about 3m40s compile
> > > time).  Runtime is also slightly in favor of 3.4, but memory usage and
> > > binary size are really fine.  Results are identical for both 3.4 and
> > > tree-ssa runs as far as correctness is concerned.
> >
> > Out of curiosity, if you use -Winline, how does the amount of inline
> > failures compare?
> 
> Uh ;) With gcc 3.4 and -Winline I get an ICE:
> 
> tramp3d-v2.cpp:47323: warning: inlining failed in call to
> 'RelationListData::~RelationListData()': function not considered for
> inlining
> tramp3d-v2.cpp:9455: warning: called from here
> tramp3d-v2.cpp: In destructor `DomainMapNode<Dom, T>::~DomainMapNode()
> [with Dom = Interval<1>, T = int]':
> tramp3d-v2.cpp:12280: internal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> 
> (gdb) c
> Continuing.
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x08325916 in expand_call_inline (tp=0x4a304b50, walk_subtrees=0xbfffe6c8,
> data=0xbfffe860)
>     at /home/rguenth/src/gcc/gcc3.4/gcc/tree-inline.c:1341
> 1341          else if (warn_inline && DECL_DECLARED_INLINE_P (fn)
> (gdb) bt
> #0  0x08325916 in expand_call_inline (tp=0x4a304b50,
> walk_subtrees=0xbfffe6c8, data=0xbfffe860)
>     at /home/rguenth/src/gcc/gcc3.4/gcc/tree-inline.c:1341
> #1  0x083242bd in walk_tree (tp=0x4a304b50, func=0x8325260
> <expand_call_inline>,
>     data=0xbfffe860, htab_=0x8dd2bf8) at
> /home/rguenth/src/gcc/gcc3.4/gcc/tree-inline.c:1755
> #2  0x083243ad in walk_tree (tp=0x4a2eeaf4, func=0x8325260
> <expand_call_inline>,
>     data=0xbfffe860, htab_=0x8dd2bf8) at
> /home/rguenth/src/gcc/gcc3.4/gcc/tree-inline.c:1803
> #3  0x0832449e in walk_tree (tp=0x4a30a524, func=0x8325260
> <expand_call_inline>,
>     data=0xbfffe860, htab_=0x8dd2bf8) at
> /home/rguenth/src/gcc/gcc3.4/gcc/tree-inline.c:1803
> (etc...)
> (gdb) print reason
> $3 = 0x946096b <Address 0x946096b out of bounds>
> 
> so probably strlen (reason) is segfaulting.  But gdb may be confused at
> -O2, too.  But I also see, that reason is not initialized inside
> expand_call_inline and there are paths in cgraph_inline_p that don't
> change *reason and still return false, so this is clearly a bug.

What paths?  the reason is supposed to be set by cgraph_inline_p just
dominating the warning.  Perhaps your modification to get leafifying
working touch cgraph_inline_p so it no longer sets the reason?
> 
> > I wonder how much the memory differences can be
> > attributed to simple fact that tree-ssa inline less because functions
> > looks bigger after gimplified.  That would explain the runtime and code
> > size difference too.
> 
> Both runs were with a leafify attribute enabled compiler, and 99% of the
> time is spent in such functions, so runtime differences can be accounted to
> different quality of optimizing the nested loops in these functions.
> 
> Code size is possibly caused by different inlining limits(?), but 5kB is
> nothing - so that maybe also accounted for by different optimizations.
> 
> > It would also suggest that the inline limits are still bit too up for
> > 3.4.  How did you measured the memory usage?
> 
> I did look at "top" output - do you have some better way to record maximum
> RSS size?

Not sure, however the top output has problem that it really depends on
size of your memory and random effects of garbage production in compiler
when ggcing takes place.  I am usually looking for peak in TOP with ggc
configured to happen always, but it takes forever to make such
experiment or I do compile with statistics and look into -fmem-report on
how much overall memory were allocated.

Honza
> 
> Richard.
> 
> --
> Richard Guenther <richard dot guenther at uni-tuebingen dot de>
> WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/