Christopher Layne writes: > On Mon, Feb 12, 2007 at 12:55:00PM +0000, Andrew Haley wrote: > > This is one of the penalties of early inlining. I suppose we could > > attempt to inline again at the end of optimization, and maybe this > > would reveal a few opportunities we'd missed, but in most cases it > > wouldn't be worthwhile. > > In general I'd agree with this as well. But for applications using > callbacks in this way as a way of using light-OO + their own namespace, > I think it would definitely be a benefit in that the overhead of function > calling was taken out of the picture. I can think of atleast one major > library which could see benefit: berkeley db. It uses these constructs for > nearly everything (e.g. data = db->get(db, NULL, key, 0)). Of course there > is no guarantee that db_get (or whatever their internal call is named) wouldn't > overstep the inlining limits, but if it didn't, a simple loop processing each > return from db_get would benefit from something like this, I would think. The > question is how to implement it in such a way that doesn't take a lot of work > or hassle. -finline-post-optimize? :P The list of optimization passes is just a list, in passes.c. There are already (at least) two inlining passes, and there's nothing to stop you adding more. It's quite likely, though, that things will break because an optimization pass isn't getting what it expects. Andrew.
