[PATCH][4.6] Properly inline all always-inline fns during early-inlining w/o iterating

[Richard Guenther]

On Sat, Jan 30, 2010 at 2:28 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> This makes iterating early inlining prettymuch useless apart
>> from the lame testcase tree-ssa/inline-3.c which does some
>> indirect inlining if the indirect function is passed directly
>> as parameter (and thus constant propagation done for parameters
>> during inlining resolves the indirect call).  Lame.  And
>> pretty artificial.
> Well, that testcase is derrived from libstdc bits used in tramp3d (and
> also some of testcases in its benchmark suite) libstdc++ tends to
> excercise these cases with small callbacks and also via virtual calls.
> They are pretty common because libstdc tends to bring stuff off
> templates this way.
>
> Paolo was asking for implementing indirect inlining for a while.
> Maritn implemented indirect inlining in main inliner that handles most
> of cases but misses devirtualization (that should be fixed in next
> release too) and also has the usual problem that missing early inlining
> leads to worse inlining decisions in long run. Especially the last was
> motivation for me to make early inlining handle this. Without this
> inliner became touchy to tune for libstdc++ benchmark suite itself.
> One can implement this via iteration or via jump functions.  I didn't
> try the second case but I would guess it will be overall more expensive.
> Except for patological case of testcase you was looking at we don't
> spend that much time in the early inlining decisions and saving the
> second pass at expense of building relatively involved IPA datastructure
> does not seem good tradeoff.  It would be win only in testcases where we
> do a lot of indirect inlning
>
> What would be our strategy to deal with indirect calls to always
> inlines?  Main inliner can handle those via indirect inlining bits, but
> early inliner doesn't.
>
> Otherwise the patch to topological ordering and idea of disabling
> real inliner at -O0 seems good to me, so I will install it to
> pretty-ipa unless you beat me.

I'm still playing with it - we seem to run into

/home/richard/src/trunk/gcc/testsuite/g++.dg/torture/pr31863.C: In
destructor 'Serializer<unsigned int, Loki::Typelist<ClassSpec<unsigned
int, A040, 40u>, Loki::NullType> >::~Serializer()':^M
/home/richard/src/trunk/gcc/testsuite/g++.dg/torture/pr31863.C:231:7:
error: statement marked for throw, but doesn't^M
Serializer<unsigned int, ClassSpec<unsigned int, A040, 40u>
>::~Serializer (this.18352_8, D.118411_7);^M
^M
/home/richard/src/trunk/gcc/testsuite/g++.dg/torture/pr31863.C:231:7:
internal compiler error: verify_stmts failed^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
See <http://gcc.gnu.org/bugs.html> for instructions.^M

when disabling IPA inliner at -O0, so I'm removing that part now.

I also wonder how recursing decide_inlining_incrementally in try_inline
should work during early-inlining.  We only ever expand inline calls
for the current function, so recursing into the callee clones seems
pointless?  In fact that the ipa-inliner calls decide_inlining_incrementally
for flattening purposes makes the latter hard to follow and possibly ugly.

Nbg network seems to have some problem, so here's a completely untested
variant that addresses some of the above and adds some comments.

Richard.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-early-always-inline
Type: application/octet-stream
Size: 13451 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20100130/b1e77eb9/attachment.obj>