inline-limit: some experimental feedback

[Daniel Berlin]

Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

> On Tue, 21 Aug 2001, Daniel Berlin wrote:
> > Errr, they are due to not inlining iterators, because we hit the
>> inlining limit.
>> I've verified this through profiling his applications.
>> What happens is we don't inline things where the call cost is less
>> than the cost to just inline, which happens quite often with
>> iterators, because we've already hit the various inlining limits.
>
> Bad, but something like that had to be the cause, else I wouldn't
> have suffered from such an incredible slow-down.
>
>> This is the main missing heuristic.
>
> Would this be hard to implement? Actually, didn't you have a patch
> addressing this?
>
>> Without it, you need to crank up the inline limit enough to get all
>> the functions where call cost exceeds inline cost to be inlined.
>>
>> When you do that, you generate enough excess code to slow down
>> compilation by a large amount.
>
> Though, even if I set the limit to 10000, the generated code is still
> measurably slower than for GCC 2.95.x.

Sure.
Code bloat isn't good for cache behavior, etc, either.

>
> Again, I'm willing to hand out our sources including a benchmark suite
> who's interested to work on this, and I can also try patches and perform
> such benchmarks by myself.
>
> Gerald
> -- 
> Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/
>

-- 
"All the plants in my house are dead -- I shot them last night.
I was torturing them by watering them with ice cubes.
"-Steven Wright