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

[Alexandre Oliva <aoliva at redhat dot com>]

On Sep 25, 2001, Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> wrote:

> 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'' ;-)

No hard feelings.  I actually overreacted to your reaction, realized
that before sending my reply, which is why I accept the responsibility
for running benchmarks in the second half of the reply, but ended up
not rewriting the first half, so it probably sounded worse than I
meant at last (but certainly not worse than I meant at first ;-)

> On 25 Sep 2001, Alexandre Oliva wrote:
>> 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.

Diego has given me pointers to running SPEC, so I'll be looking into
it, probably tomorrow.

> 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

Sounds reasonable to me.  But I believe we'll already earn some
benefits by enabling this in 3.1.  For one, the RTL inliner can't
inline alloca, but the tree inliner can.  I believe there may be other
cases in which the tree inliner will outperform the RTL inliner, if
not for handling additional situations, at least for exposing inlined
trees earlier, which allows optimizations such as constant folding to
be applied in tree form, where they can do a better job than the
corresponding RTL forms.  Division on SH (implemented as a libcall,
due to the lack of a division instruction) comes to mind.  Some time
ago, I found a code snippet that wouldn't be optimized in C as well as
it was in C++, and the reason was that C++ performed the optimization
in trees, where it was still possible, but C tried to do it in the RTL
level and failed because the RTL fragment was too complex for it to
handle.


That said, I think patch #3 may still need some more work.  It fell
onto me a few minutes ago that it may have broken -finline-functions:
I don't see where functions would be implicitly marked as inline as I
thought they would.  I think it was the RTL inliner that handled this
flag especially, but with patch #3 it's never given a chance to do so.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me