This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: attribute((leafify)) for 3.4
> On Fri, 31 Oct 2003, Jan Hubicka wrote:
>
> > > On Thu, 30 Oct 2003, Richard Guenther wrote:
> > > I missed to mark the cgraph edges created after inlining, with this chunk
> > > added I get leafify behavior as wanted. But I still see these artificial
> > > libstdc++ functions not inlined - they seem to be triggered by temporary
> > > objects created inside the loop and never optimized away (as 3.3 did).
> > > I'll try to dig further and come up with a testcase.
> > >
> > > (Final) patch is attached. It breaks debugging (-g3) with the following
> > > ICE:
> > >
> > > /home/rguenth/ix86/pooma/tat-serial-gcc34/pooma/linux/src/Evaluator/InlineEvaluator.h:102:
> > > internal compiler error: in gen_subprogram_die, at dwarf2out.c:10607
> > > Please submit a full bug report,
> > > with preprocessed source if appropriate.
> > > See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> > > make: *** [tramp3d.o] Error 1
> > >
> > > It seems that unnecessary (inlined) function bodies are emit and
> > > debugging is confused by this. But I really dont know how to prevent
> > > this. Linking is fine. Any idea?
> >
> > Dwarf2out emits abstract debug infromation for functions that are
> > inlined.
> > This crash usually happens when function is inlined but the debug
> > information is missing. You probably need to fix:
> >
> > /* Return true when the DECL can possibly be inlined. */
> > bool
> > cgraph_function_possibly_inlined_p (tree decl)
> > {
> > if (!cgraph_global_info_ready)
> > return (DECL_INLINE (decl) && !flag_no_inline);
> > return cgraph_node (decl)->global.inlined;
> > }
> >
> > To return true for functions inlined by leafifying.
>
> Ah, ok. I missed this, fixed by setting e->callee->global.inlined to 1 in
> cgraph_decide_inlining_leafify().
>
> > > +static void
> > > +cgraph_decide_inlining_leafify(struct cgraph_node *node)
> > > +{
> > > + struct cgraph_edge *e;
> > > + if (node->aux)
> > > + return;
> > > + for (e = node->callees; e; e = e->next_callee)
> > > + {
> > > + e->maybe_inline_call = 1;
> > > + cgraph_decide_inlining_leafify(e->callee);
> > > + }
> >
> > In general we are trying to avoid recursion over loop depth. You will
> > also need to behave somewhat sanely in the case of recursion (either not
> > inline the reucursive call or error out.
>
> It's tail recursion, so it shouldn't be bad. Also I moved node->aux
It is not tail recursion. You still have stack depth depending on
inlining depth of your leafify function. But during inlining we get
this too, so I guess it is not bad.
> initialization up to avoid going endlessly through callgraph loops.
> Recursive inlining seems to be prevented somehow at least for not-direct
Ah, I see, there is still recursive inlining preventing code in
tree-inline I wanted to remove after killing old heuristics code.
OK, still you mark maybe_inline in cyclic way in the callgraph that will
eventually bring you problems if you attempt to get right the code size
estimation (BTW you should at least increase global_insns during
leafifying or you will get the leafifed function inlined too many times)
> I won't submit this officially for 3.4, as I dont have a copyright
> assignment yet and I suspect this would last too long to be accepted late
> in stage 3 anyways. Also the concept of leafify needs some arguments.
> Apart from this I think it is trivial for you to implement this
> functionality after cleanup in 3.5, so I wont need to fiddle around with
> copyright assignments.
OK, I will try to get into this soon.
Honza