Tree-ssa status with POOMA

[Richard Guenther]

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.

> 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?

Richard.

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