This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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.
Attachment:
fix-early-always-inline
Description: Binary data
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |