Re: Tree inlining for the C front end (part 3 of 3)

[Jan Hubicka <jh at suse dot cz>]

> On Sep 25, 2001, Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> wrote:
> 
> > We really, really, really should avoid having a huge regression in
> > these respects as we had for the C++ frontend in GCC 3.0 and 3.0.1.
> 
> I doubt it would affect C as much as it did C++.  The absence of
> implicit inline in C, as is the case for member functions defined
> inside a class body in C++, will most definitely make a huge
> difference for C.
> 
> Anyway, I don't think imposing such requirements on me is fair.  I'm
> not introducing the tree inlining infrastructure, I'm just adopting
> for C what's already in place for C++.  So, if you're so much
I would agree with this point.
In long term it is kind of a must to drop the inlining-on-rtl code as
1) it does relativly poor job
2) we want to see inlined code for AST optimizers

so the tree inlining adopted to C is step in right direction.  We do have
it in C++ for a while and maybe it has been mistake to introduce it there
when it causes so numberous problems, maybe it was not, as longer term
modernization of compiler sometimes worth temporary regressions.

I would be happy with 0% difference, I would accept even -2% on specs or
something (I doubt it has power to waste quality so much) and I would definitly
not require 3% as suggested by Daniel.

Honza