On Sunday 27 February 2005 14:58, Jan Hubicka wrote: > > >is a problem for a few people, but if you look at the performance > > >numbers of things like SPEC, CSiBE, and MySQL, there doesn't appear > > >to be any performance problem. But your patch will probably still > > >blow compile time through the roof for those applications as well. > > > > I don't know. But I also think our inlining limits are way too high, > > at least unnecessary high with the patch applied. I'll try do find > > some more representative packages to test - any hints? In the mean > > time would it be ok to apply the patch to mainline to have the automatic > > testers do some tests and then afterwards maybe revert it, if we do > > not like it? I'll take the previous approval of Jan as taken back > > for now. > > Well, I still think that the metric without artificial assignemnts is > more realistic
And you know this how? When I last toyed with this, I compared the actual number of RTL insns generated for a function with the estimate we made. I have not seen a comparison of that so far. Maybe we are now way underestimating the sizes. > so the path of using your patch in combination of > re-benchmarking the inlining limits is proper way to go. In principle, yes. But we really need to investigate more carefully than this. Especially if this is intended for 4.0 (and IMHO it is too late for that). > I would not > expect drastic slowdown in testcases that don't suffer from abstraction > penalty. I will test it on SPEC tonight and send you a results > tomorrow so lets see how intuition works here. Maybe you could test DLV and Gerald's other C++ benchmarks as well. > The basic idea is that we need to recognize "forwarder" functions as > being free to get sane performance on funny C++ template codes. I was > even thinking about some kind of pattern matching for common cases (ie > functions just passing their arguments to other functions and similar) > and forcing their costs to be CALL_INSN_COST, but didn't get across that > yet. Another idea might be to give "small" functions with one or more constant arguments a smaller inlining penalty. > So we should slow down compilation of testcases like tramp3d to > get sane performance and not affect too much lower level code, like > SPEC. Or have different inlining heuristics for C++. Gr. Steven
