C++ inlining heuristics changed (3.0.1)

[Kurt Garloff]

On Fri, Aug 24, 2001 at 12:49:10PM +0200, Gerald Pfeifer wrote:
> As promised, updated with data for your second patch.
> 
> First the build benchmarks, then run-time benchmarks:
[...]
> Summary: Still worse than 2.95.3 in most cases, but significantly better
> than 3.0.1 (which in turn is quite a bit worse when compared to 3.0). The
> second patch is an improvement over the first one.

OK, here is v3 of the patch, with only slight adjustments:
The linear function to limit the recursive inlining now has only half the
slope. (-1/32). Anf when accounting, we correctly substract 1 because we
save the call tree statement, so we do single statement inlines at no cost
for the recursive inlining accounting. (As far as I could see, we save just
one tree statement, but I might have overseen something.)

This should not change much, except that it should yield better behaviour
for some cases that were throttled a bit too much when inlining recursively.
(I'd guess this happens for the expression template stuff.)

I would also be interested how this patch performs when changing
-finline-limit. In my tests, performance starts to drop significantly
somewhere between 400 and 350. It might be, that for some of your tests,
1000, or 1500 can yield better results than the default.

The docu is now adapted in the .texi file, as it should.

> I'm still waiting for approval to commit the first patch (which doesn't
> require the paperwork) on both branches.

Did it happen meanwhile?

Patch v3 attached and available via
http://www.garloff.de/kurt/freesoft/gcc/

Regards,
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7jWl9xmLh6hyYd04RAsPGAKCSW5vIcs9DnM9hmNDB/XW7qvQBWwCgkcbS
n/woFQqGrL6k96rVIi/rmF4=
=catA
-----END PGP SIGNATURE-----