Re: [tree-ssa] Fix function body estimation

[Jan Hubicka <hubicka at ucw dot cz>]

> On Sat, Oct 18, 2003 at 10:26:55PM +0200, Jan Hubicka wrote:
> > I see, why do we genericize C trees by gimplifying it?  Should not we
> > keep C nodes as they are and gimplify them when we are asked to
> > gimplify?
> 
> I assume you're talking about the call to c_gimplify in finish_function.
> The tree inliner only works on GENERIC.  It doesn't work on C trees.
> So we need conversion to GENERIC before inlining can happen.

OK, this brings back the qustion about definition of GENERIC.  If
GENERIC is what tree.def contains, it is actually supperset of C trees.
If it is something else, where do I find documetnation so I can write
code size estimation function?
> 
> > (It probably won't work directly,  I attempted to call genericize hook
> > from cgraph_analyze_function instead from finish_function so we don't
> > genericize functions we never use and it didn't work dying in very
> > strange self referencing trees, not at all sure why)
> 
> The only problem I have with this approach is that we're generating more
> and more errors/warnings from within the gimplifier/optimizers.  Stuff
> like function returns without value etc.  In order to make those work,
> we can't simply discard these functions.

Right, not sure whether delaying genericizing process make sense then.
We will probably end up doing it just to get diagnostics right on all
functions anyway.
(well perhaps for C++ and automatically generated functions this may
make diference).
> 
> Of course, teaching cgraph about this and have it perhaps save/restore
> flag_syntax_only around compiling these functions might work.
> 
> Anyway, not sure why moving the call to the gimplifier didn't work.

Me neither.  I will try to return to that once I get past the
-funit-at-a-time issues.
Looks like last patch fixed the reload misscompilation too (not sure why
as there has been absolutely no local statics involved, so I am
re-bootstrapping now)

Last problem I have with -funit-at-a-time are the new unused variables
warnings comming from function inlining.  Would be OK to commit the
patch to initialize these variables so we bootstrap? (or you know of
better sollution - it seems to me that we need to move this stuff into
pre-inlining optimizer as having warnings dependent on how much we
inline is weird)

Honza
> 
> 
> r~