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

[Jan Hubicka <hubicka at ucw dot cz>]

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

This seems like missing fixup_cfg pass that is currently invoked from 
inliner's transform method.  I am currently on trip to Leipzig, I will look
into it after returning at Monday.

Also note that I am not convinced that current way of giving precedence to
always_inline edges in reverse postorder is enough.  It is good as herustics,
but doing topsort with breaking cycles on "unimportant' edges seems harder

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

I will look into this day after tomorrow, but isn't this for handling flatten
in later inliner where we do have clones?

Honza