This is the mail archive of the gcc@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]

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

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

Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]