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

[Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>]

On 25 Sep 2001, Alexandre Oliva wrote:
> Anyway, I don't think imposing such requirements on me is fair.

Well, I hope you know this was nothing personal, just ``once bitten,
twice shy'' ;-)

On 25 Sep 2001, Alexandre Oliva wrote:
> The results below are for a full bootstrap [...]

Thanks!

> An increase of almost 3%, unfortunately.  Is this too much for a
> start?

Personally, I'd say it's (on the border of being) acceptable, if --
and only if -- the generated code improves a bit, or at least does
not get worse.

> In any case, this work was never expected to improve performance or
> compile-time by itself.  At this stage, inlining trees is no different
> from inlining RTL.  But it's a step towards the direction of enabling
> other optimizations on trees, optimizations that will only apply to
> inlined functions if they're inlined as trees.  And that's where we're
> likely to have a significant win.

I think we should install this on mainline before GCC 3.1 branches
only if we are sufficiently sure that we will earn the benefits of
those optimizations in GCC 3.1; making GCC 3.1 a slower compiler
without any benefits _visible_ _to_ _the_ _user_ should be avoided.

> In any case, I'd like very much to have patches #1 and #2, that move
> the tree inlining infrastructure to a more language-independent
> location, still be installed in mainline, to avoid divergence and ease
> merging from the branch.  This would have a minor impact in C++
> compile times, due to the introduction of hooks, but I hope that's not
> asking too much.

I cannot approve these patches, but the approach per se makes a lot of
sense to me.  (I'm all for cleaning up the compiler and creating better
infrastructure and better interfaces, but a strong focus still should be
kept on usability and performance, that's why I raised this issue.)

Gerald