This is the mail archive of the
mailing list for the GCC project.
Re: [unit-at-a-time] Java inlining woes
- From: Jeff Sturm <jsturm at one-point dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: gcc at gcc dot gnu dot org
- Date: Sun, 24 Aug 2003 01:50:35 -0400 (EDT)
- Subject: Re: [unit-at-a-time] Java inlining woes
On Sat, 23 Aug 2003, Jan Hubicka wrote:
> > How does this work in other languages? I'm wondering about e.g. "extern
> > inline" where I'd guess the function is also not expanded before its body
> > is cloned.
> I am not 100% sure I understand your problem,
I'm not entirely sure I understand either. It's not easy to pinpoint
the root of the problem as the frontend, cgraph, tree-inline or
> but in general, the
> function expansion is supposed to be mostly noop on the program
> rerpesentation tree so functions can be expanded at any time with no
> interference with inlining them or expanding others.
It would sure be nice if it were so. Among the interesting things that
happens during expansion is that Java-style blocks are converted into
blocks that dwarf2out can understand (specifically, BLOCK_EXPR_BODY info
is replaced with BLOCK_SUBBLOCKS). Block nodes also have their TREE_USED
flag marked when expanded.
Anyway, I've discovered an important clue: the C inliner sets
BLOCK_ABSTRACT_ORIGIN of the outermost block cloned from the inlined
function. The Java inliner does not. I suspect that's part of my
problem, since that is how gen_block_die would have first created the
DIE for the inlined function.
I may still abandon this for 3.4 and wait for tree-ssa, where it is
far simpler. Functions are lowered to GIMPLE before they are inlined or even
analyzed by cgraphunit, so on tree-ssa making unit-at-a-time work for any
frontend should be good enough for all.